Toy compilers (was Re: gotos)
Walter Bays
walter at garth.UUCP
Wed Jun 1 03:04:05 AEST 1988
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 at wsccs.UUCP> terry at 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
------------------------------------------------------------------------------
More information about the Comp.lang.c
mailing list