cottrell@nbs-vms.arpa (COTTRELL, JAMES) (12/02/85)
/* > Look, those of you who are new to this discussion: it has already > been incontrovertibly shown that cottrell@nbs is one of those > irremediably brain-damaged people who think that all computers > should look like VAXen. Yes. Reasonable. It is not the only one. There are others. > He's even shown VMS-loving tendencies. I hate VMS. What are you talking about? > So, let's not waste net time trying to shout him down, eh? > ;-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-);-) > Jim, if you want to flame me, let's do it privately, eh? But it's OK for you to insult me publicly, eh? GFY. > > Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} > > [ME] ...Portability to lesser machines should be done *by the porter*. > > That's why they call it porting. After all, this is still easier to do than > > rewriting the program. > > > > I can live with the new ANSI C recasting all my parameters for me. > > I refuse to cast parameters to the `correct' type. And I refuse to > > work on any machine where I need to. You want it, you fix it. > > Translated, what this says is "I don't care whether my programs are > portable, so long as they run on the machines I care about right now". > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Exactly. Listen folx, I'm getting sick of this righteous attitude toward my opinions on portability. If I was rich, I would design a machine that had 11 bit characters, 19 bit shorts, 37 bit ints, and 51 bit longs. It would be base 3, middle endian; floating point would be BCD exponents with EBCDIC mantissas. I'd love to see X3J11 try & be portable with that. If you don't like my opinions, fine. But you don't have to insult me. Any fool can do that. There are a whole lot worse & uninformed opinions on this network. Just for a moment step outside your way of looking at things and consider what if it was my way. Do you *really* enjoy contorting your code so that it will run on every conceivable machine? Who TF gave INTEL permission to create the abominable notion of segments? And who TF gave some joker permission to create a compiler with `small-model' & `large-model' concepts? Absurd! More forgivable mistakes were non-byte addressible 16 bit minis. But who would seriously consider anything but an 8 bit byte with ASCII as the native character set (except IBM or their lookalikes) today? The future is now. Don't wallow in the past. Throw out your Z80's etc. Bring out your dead. jim cottrell@nbs */ ------
gwyn@BRL.ARPA (VLD/VMB) (12/02/85)
Yes, VAX-like machines are simpler to program, especially at the assembly language level (except for having to remember the large instruction set). But it is not much harder to write C code that would port to your hypothetical example machine (19-bit shorts, base 3, etc.) than it is to write it for a VAX. Why limit the future portability of your code unnecessarily? Who knows, someday you may have to use one of the weird machines, and instead of cursing how brain-damaged it is you could instead be happy how you provided portability for your code the day you wrote it. In particular, people who think ints and pointers should be the same size are ruling out a lot of possibly nice machine architectures. Use C data types by the rules and you seldom have to worry about the whole issue.
jsdy@hadron.UUCP (Joseph S. D. Yao) (12/03/85)
In article <213@brl-tgr.ARPA> cottrell@nbs-vms.arpa (COTTRELL, JAMES) writes: >But it's OK for you to insult me publicly, eh? GFY. In this one, Jim, you're absolutely right & so I'm going to waste a few bytes for a public apology. What was intended as a clever twist on the message it was answering came out as a gratuitous insult. I keep telling myself not to try anything "clever" after midnight ... I apologise. But, would you mind telling me what "GFY" stands for? I can't find it in any of my lexicons ... I even agree with you that the VAX has one of the nicer architectures to work with in the industry. I agree with you that segments (and the whole architecture of the 80X86 machines) are abominable. And I do n o t enjoy contorting my code to fit a lot of odd machines. But I enjoy even less taking my code (which I think I understand), or worse yet someone else's code (which may or may not have been written for comprehensibility), if it was originally engineered to work only on one machine, and tearing my hair out finding all the clever little tricks that couldn't possibly work on my machine. (Since some of the machines I work on are VAXen, you'd think this was less of a problem -- but at least one is System V v. 2 r. 2 and then some.) Out of concern for my own future sanity (what there may be of it ;-)) and courtesy for others who may have to live with my code, I make the slight extra effort to try to always code so that I can use my code an any of my systems. And I use the word "slight" advisedly. By making these practices into habits, most of them are no pain at all to include in new code; and I do not spend hours agonising over whether each construct will break on some obscure machine. Only if it's at all likely that it will be used on that obscure machine; and then, it usually doesn't take hours. The gain? Well, I have a number of tools, including a set of file- system repair tools, that will run under Xenix, System V, 4.2 BSD, 4.1 BSD, V7, and I think even V6 (although it's been so long since I used that that I've stopped checking). Minimal effort was needed to port them, except for some of the 4.2 file-system programs. (4.1 is closer to System V than either is to 4.2!) I think it was worth it, since I have to work on all of these. When I get a chance to post them, I'll bet you'll be happier than if I had hard-coded my machine in, too. But, as I said before, I know that my arguments don't really impress you, and yours don't all impress me. I was just asking that we stop slinging stuff around the net -- and here I am doing it again. It must be after midnight. Bye. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
brooks@lll-crg.ARpA (Eugene D. Brooks III) (12/03/85)
In article <213@brl-tgr.ARPA> cottrell@nbs-vms.arpa (COTTRELL, JAMES) writes: >If I was rich, I would design a machine that >had 11 bit characters, 19 bit shorts, 37 bit ints, and 51 bit longs. >It would be base 3, middle endian; floating point would be BCD exponents >with EBCDIC mantissas. I'd love to see X3J11 try & be portable with that. How fast is it and how much will it cost? Our Cray almost as crazy and X2J11 had better be portable to it. So whats the score folks? Is X3J11 portable to Cottrell's new machine?
laura@l5.uucp (Laura Creighton) (12/03/85)
In article <213@brl-tgr.ARPA> cottrell@nbs-vms.arpa (COTTRELL, JAMES) writes: >If you don't like my opinions, fine. But you don't have to insult me. >Any fool can do that. There are a whole lot worse & uninformed opinions >on this network. Just for a moment step outside your way of looking at >things and consider what if it was my way. Do you *really* enjoy >contorting your code so that it will run on every conceivable machine? But I don't have to contort my code. All I had to do was work with Henry Spencer. You come out of that thinking portably, and then you write portable code without contortions. The contortions come when you have to port SOMEBODY ELSE'S code and they DIDN'T THINK PORTABLY. What is there to do? You can't buy all of these people off. If I were sufficiently rich i would pay those people to stay at home and not write code until they were willing to write protably -- but of course I don't have that kind of cash. -- Laura Creighton sun!l5!laura (that is ell-five, not fifteen) l5!laura@lll-crg.arpa
jack@boring.UUCP (12/04/85)
In article <219@brl-tgr.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes: [Replying to an article about Jim Cotrell's new machine] > But it is not much harder to >write C code that would port to your hypothetical example >machine (19-bit shorts, base 3, etc.) than it is to write >it for a VAX. One problem. Does the ANSI standard specify what left- and right-shifts do, w.r.t. arithmatic values? And &|!^ etc? :-), of course. Followups on boolean arithmatic (if you can call it that) on terniary machines should go to net.arch. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
jsdy@hadron.UUCP (Joseph S. D. Yao) (12/04/85)
In article <6698@boring.UUCP> jack@boring.UUCP (Jack Jansen) writes: > One problem. Does the ANSI standard specify what left- >and right-shifts do, w.r.t. arithmatic values? And &|!^ etc? I believe that this falls under the heading, "say what you mean." If you m e a n that bits should shift left, say so; if you instead m e a n that you wish to multiply (resp., divide); say that, also! Your compiler (at least, with optimisation on) should be able to do the conversion if it speeds anything up; and future generations of software maintenance personnel will sing your praises for doing something in a way that is comprehensible to both man and machine. >>Is it after midnight yet? ;-)<< -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
gwyn@BRL.ARPA (VLD/VMB) (12/05/85)
Most C applications have no need to use bitwise operators. && || and ! are well-defined for any arithmetic quantity, regardless of the base. Bit operations are certainly useful at times, such as when twiddling device registers or when writing bitmap display code, but I feel they are often used when they're not appropriate. If anyone is seriously interested in ternary bases, check out Vol. 2 of Knuth.
henry@utzoo.UUCP (Henry Spencer) (12/06/85)
> >If I was rich, I would design a machine that > >had 11 bit characters, 19 bit shorts, 37 bit ints, and 51 bit longs. > >It would be base 3, middle endian; floating point would be BCD exponents > >with EBCDIC mantissas. I'd love to see X3J11 try & be portable with that. > > ... > So whats the score folks? Is X3J11 portable to Cottrell's new machine? X3J11, probably. Cottrell's programs, quite possibly not. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
bright@dataioDataio.UUCP (Walter Bright) (12/10/85)
In article <119@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >I believe that this falls under the heading, "say what you mean." >If you m e a n that bits should shift left, say so; if you instead >m e a n that you wish to multiply (resp., divide); say that, also! >Your compiler (at least, with optimisation on) should be able to do >the conversion if it speeds anything up. Almost but not quite true. A compiler CANNOT normally replace a divide by a right-shift if it is an integer divide. This is because a right shift of a negative integer is not the same as a divide. { int i; unsigned u; i *= 4; ==> i <<= 2; u *= 4; ==> u <<= 2; i /= 4; ==> i >>= 2; WRONG! u /= 4; ==> u >>= 2; } Since divides are relatively expensive, one would want them replaced by shifts whenever possible. The only way you can get the compiler to do this is by casting the int to unsigned before the divide is done (but check the output of the compiler to make sure it is doing things correctly).
thomas@kuling.UUCP (Thomas H{meenaho) (12/21/85)
In article <874@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: >Almost but not quite true. A compiler CANNOT normally replace a divide >by a right-shift if it is an integer divide. This is because a right >shift of a negative integer is not the same as a divide. However most useable processors provide arithmetic shifts which will give the right result even if it is a signed divide. -- Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden Phone: +46 18 138650 UUCP: thomas@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!thomas)
augustss@chalmers.UUCP (Lennart Augustsson) (12/23/85)
In article <864@kuling.UUCP> thomas@kuling.UUCP (Thomas H{meenaho) writes: >However most useable processors provide arithmetic shifts which will give >the right result even if it is a signed divide. Replacing a divide with a signed shift doesn't solve the problem. Consider the following: decimal binary -1 / 2 = 0 11111111 / 10 = 00000000 -1 >> 1 = -1 11111111 >> 1 = 11111111 Most machines behave like this when dividing, i.e. they divide the absolute value of the operands and then sets the correct sign. There are machines (e.g. NS 32000) which provide a divide instruction with the other behaviour. -- Any resemblance of the opinions above to real opinions, living or dead, is purely coincidential. Lennart Augustsson UUCP: {seismo,philabs,decvax}!mcvax!enea!chalmers!augustss ARPA,CSnet: augustss@chalmers.csnet
john@frog.UUCP (John Woods, Software) (12/24/85)
> In article <874@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: > >Almost but not quite true. A compiler CANNOT normally replace a divide > >by a right-shift if it is an integer divide. This is because a right > >shift of a negative integer is not the same as a divide. > > > However most useable processors provide arithmetic shifts which will give > the right result even if it is a signed divide. > -- > Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden Wrongo: Consider the following program: main() { int three = -3; printf("%d %d\n", three / 2, three >> 1); } What does it print? -1 -2 Division (usually) rounds negative numbers to zero, ASH-ing right to -infinity. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA The Pentagon's Polygraphs: Witchcraft for witchhunts.
cmt@myrias.UUCP (Chris Thomson) (12/25/85)
> >Almost but not quite true. A compiler CANNOT normally replace a divide > >by a right-shift if it is an integer divide. This is because a right > >shift of a negative integer is not the same as a divide. > > However most useable processors provide arithmetic shifts which will give > the right result even if it is a signed divide. The first is correct, the second is WRONG. -1/2 is 0 not -1.
bright@dataioDataio.UUCP (Walter Bright) (01/02/86)
In article <864@kuling.UUCP> thomas@kuling.UUCP (Thomas H{meenaho) writes: >In article <874@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: >>Almost but not quite true. A compiler CANNOT normally replace a divide >>by a right-shift if it is an integer divide. This is because a right >>shift of a negative integer is not the same as a divide. >However most useable processors provide arithmetic shifts which will give >the right result even if it is a signed divide. Ok, try this program: main() { printf("-3/2 = %d\n-3 >> 1 = %d\n",(-3)/2,(-3) >> 1); } I think you'll find the results are different, even when the compiler does an arithmetic right shift! (The difference is the direction in which rounding occurs.)
ron@brl-sem.ARPA (Ron Natalie <ron>) (01/04/86)
> In article <864@kuling.UUCP> thomas@kuling.UUCP (Thomas H{meenaho) writes: > >In article <874@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: > >>Almost but not quite true. A compiler CANNOT normally replace a divide > >>by a right-shift if it is an integer divide. This is because a right > >>shift of a negative integer is not the same as a divide. > >However most useable processors provide arithmetic shifts which will give > >the right result even if it is a signed divide. > > Ok, try this program: > > main() > { > printf("-3/2 = %d\n-3 >> 1 = %d\n",(-3)/2,(-3) >> 1); > } > > I think you'll find the results are different, even when the compiler > does an arithmetic right shift! (The difference is the direction in > which rounding occurs.) Actually, K&R states that the truncation from an integer divide of negative numbers is machine dependant -3/2 could correctly be -2 or -1 depending on the machine. The only guarantee that they make is that (a/b)*b + a%b must be equal to a .
bright@dataioDataio.UUCP (Walter Bright) (01/07/86)
In article <615@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >> >In article <874@dataioDataio.UUCP> bright@dataio.UUCP (Walter Bright writes: >> >>Almost but not quite true. A compiler CANNOT normally replace a divide >> >>by a right-shift if it is an integer divide. This is because a right >> >>shift of a negative integer is not the same as a divide. > >Actually, K&R states that the truncation from an integer divide of negative >numbers is machine dependant -3/2 could correctly be -2 or -1 depending on >the machine. The only guarantee that they make is that > > (a/b)*b + a%b must be equal to a You are correct. However, the point is that on most machines the DIVIDE instruction works one way, and the ARITHMETIC_RIGHT_SHIFT works another way. If the compiler replaces a divide with a right shift, it is WRONG if in doing so it changed the result of the computation. That is, the following two pieces of code better produce the same result: k = -3; i = 2; j = k/i; k = -3; j = k/2;