smart compilers

[Norman Diamond]

> >  Optimizing compilers are very useful
> >  as long as the optimization is optional (or at least can be turned
> >  off when the code involved may be sensitive to optimization).
> 
> Not quite fair to compilers.  If optimizing breaks programs which conform
> to the language definition, the optimizer is broken.  If optimizing breaks
> a program because the program is non-conforming (as, say, a program which
> depends on order of evaluation in most languages), the program is at fault.
> Using C assignments to manipulate or busy-wait on device registers is a
> gray area, which is why (1) optimizers zing people on such code
> periodically and (2) a mechanism like `volatile' has been proposed.
> 
> FORTRAN is less susceptible to clashes with the optimizer due to the
> device-register sort of hassle but more susceptible to poor programming
> such as parameter/COMMON aliasing, misunderstanding of modifying
> initialized COMMON, etc.

It is usually necessary for optimizations to break certain obscure points
that conform to the language definition, e.g. which order STATEMENTS are
executed in so that code can be moved out of loops.  Many useful optimizations
cannot be done when more than 99.9% of the language definition must be
respected.

In turn, this is the reason that optimizations must be optional.

And if these optimizations were not available, clamouring might start for a
return to assembly languages.

-- Norman Diamond

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy at waterloo.csnet
ARPA:  ndiamond%watdaisy%waterloo.csnet at csnet-relay.arpa

"Opinions are those of the keyboard, and do not reflect on me or higher-ups."