campbell@maynard.BSW.COM (Larry Campbell) (05/03/88)
In article <504@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes:
<> ... I happen to write code that uses
<>
<> for( ;;) {
<> }
<>
<>instead of
<>
<> while( 1) {
<> }
<>
<>too, as I need the best speed out of the hardware I can get and the 'for'
<>avoids a test instruction being generated. Certainly, the 'while' is better
<>at self-documenting, but it isn't the right tool for the job.
For someone who believes in using the right tool for the job, you seem
to have chosen a pathetically lame compiler. The compiler should generate
the same code in both cases, since (1) is obviously a compile-time
constant expression.
It's penny-wise and pound-foolish to buy a toy compiler, and then feel
compelled to write code like the above. In the long run, the
maintenance and support costs you incur will vastly overshadow the few
hundred dollars you might have saved by skimping on the compiler.
P.S. - I just compiled a "while (1)" loop on my system, which has one
of the wimpier C compilers around. It generated the right code
(i.e., no test instructions, just a jump to the top of the loop).
And this was without -O.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846firth@sei.cmu.edu (Robert Firth) (05/04/88)
In article <1080@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >P.S. - I just compiled a "while (1)" loop on my system, which has one > of the wimpier C compilers around. It generated the right code > (i.e., no test instructions, just a jump to the top of the loop). Same here. I compiled the BCPL equivalent WHILE TRUE DO { Thing } and got out LA4: code for Thing BRB LA4 This is so obvious a micro optimisation I find it hard to believe any compiler won't do it.
terry@wsccs.UUCP (Every system needs one) (05/17/88)
In article <1080@maynard.BSW.COM>, Larry Campbell writes: | In article <504@wsccs.UUCP> I wrote: | <> ... I happen to write code that uses | <> | <> for( ;;) { | <> } | <> | <>instead of | <> | <> while( 1) { | <> } | <> | <>too, as I need the best speed out of the hardware I can get and the 'for' | <>avoids a test instruction being generated. Certainly, the 'while' is better | <>at self-documenting, but it isn't the right tool for the job. | | For someone who believes in using the right tool for the job, you seem | to have chosen a pathetically lame compiler. The compiler should generate | the same code in both cases, since (1) is obviously a compile-time | constant expression. Not all compilers do, however. | It's penny-wise and pound-foolish to buy a toy compiler, and then feel | compelled to write code like the above. In the long run, the | maintenance and support costs you incur will vastly overshadow the few | hundred dollars you might have saved by skimping on the compiler. You are neglecting the fact that "for(;;)" takes less code in "portable to lame compilers" fashion. When a lame compiler is all you have, better to write code that works on lame and un-lame (healed?) compilers alike. You also neglect the fact that the majority of software companies that have the same software on a *lot* of machines (we have code that runs on over 140 with only minor #ifdefs, usually relating to SysV vs. Berklix vs. VMS, etc.) doesn't necessarily own either the machines or the compilers. In addition, priveledges on porting machines are usually limited, so installing then removing a compiler is out of the question. Time, also, is generally limited to several hours, and if you can't port your 65000 lines of code relatively quickly (say 40 minutes at most), you won't have enought time to master a tape or remove your code. Note that this totally neglects the need to make tapes within that time frame if you are porting to something like a Northern Telecom system which can only read Northern Telecom tapes while purporting to be QIC-24 compatible. Generally, it is better to be portable to many compilers rather than having to buy many machines or have them sent to you, let alone the expense of having to buy a compiler that will compile your code because you're not portable to the compiler that comes with the machine and is supported by the manufacturer. | Terry Lambert UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry | | @ Century Software OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'Admit it! You're just harrasing me because of the quote in my signature!' |
walter@garth.UUCP (Walter Bays) (05/31/88)
An aside to the debate over whether to write for a good compiler or a bad one, whether to use 'while(1)' or 'for(;;)', ... In article <535@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >You are neglecting the fact that "for(;;)" takes less code in "portable to >lame compilers" fashion. When a lame compiler is all you have, better to >write code that works on lame and un-lame (healed?) compilers alike. >(we have code that runs on over >140 with only minor #ifdefs, usually relating to SysV vs. Berklix vs. VMS, >etc.) The problem is pervasive and not likely to disappear soon. Portable programs cannot be optimal on all systems. A programmer using a "pcc-type" compiler will often put "optimizations" in the source code like register declarations, accessing arrays through pointers, loop unrolling, and assignment of common subexpressions to temporary variables. Unfortunately, many of these hurt performance with an optimizing compiler by interfering with the compiler's attempts to perform the same optimizations. With 140 machines to support, you can't maintain separate versions to get the most out of every compiler. You write for the largest / most important part of your customer base, and take some performance loss for especially good or especially bad compilers. I wonder whether it would be feasible to add one more set of #ifdef's for compiler quality as well as OS, like: $ # :-) $ cc -DBSD -DWIMP hello.c # weak compiler $ cc -DSYSV -DRAMBO hello.c # optimizing compiler -- ------------------------------------------------------------------------------ I said it, not them. E-Mail route: ...!pyramid!garth!walter (415) 852-2384 USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 ------------------------------------------------------------------------------