Re^3: gotos

[Brian T. Schellenberger]

In article <2606 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
|In article <1988Apr24.004842.3251 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
|# Remember that there are two separate issues here:  what you write, and the
|# code the compiler generates for it.  With modern compilers, the two are
|# often quite different.
|
|This may be highly undesireable in a language used for programming operating
|systems, where the programmer needs something approaching WYSIWYG capability.
|C is eminently such a language.  I'd rather program a "goto" using an older
|technology compiler then put in a function call, if your proposed whoop-de-do
|hyper-global-optimizing compiler is liable to turn my REAL function calls into
|inline code, unbidden.  (OOPS, so THAT'S why I got a 4-megabyte kernel!!!)
|This isn't just hay.  I see on this net reports that PC C-compilers hyper-
|optimize this way.  Their benchmarks beat the band, but the executables they
|make are elephantine.

I've seen this same point made before, without rebuttal, so I'm going to this
time.  The fact that certain compilers for the IBM Piece of Crap computer
produce really fat code due to overzealous in-line code production (a fact which
is not established, but never mind that) is *not* an argument for making C into
nothing more than a pretty-printer for assembly language.

Optimization can apply to space or time, or both.  The fact that certain 
compilers don't make the tradeoffs you want merely means that they are not
the ones you want.  An ideal optimizing compiler would allow you to tell it
the relative priorities of these goals.

There are many people programming in C, not because they are doing systems
programming, but because it is the most similtaneously portable and useful
language available.  In any case, any quality implementation allows you turn
off all optimization.  And if it doesn't, don't buy it.
-- 
                                                         --Brian.
(Brian T. Schellenberger)				 ...!mcnc!rti!sas!bts

. . . now at 2400 baud, so maybe I'll stop bothering to flame long includes.