smart compilers

[oacb2]

> 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.

NO! NO! NO!.  An optimizer that changes the meaning of the code is broken
I agree that there is some discussion needed at to just what code should
mean, particularly in languages like C which are often used as fancy
assemblers, but at a very minimum an optimizer should never affect the
results of a program provided

	- no variables are changed by asynchronous processes unknown to the
	  compiler.

	- no variables whose values are undefined by the language specification
	  (e.g. the DO loop index in FORTRAN after normal completion of the
	  loop).

	- timing is not considered a result of the program.

If an optimizer cannot be written that does not change the meanings of
programs with these minimal requirements we are better off without the
optimization.  I'm more than a little tired of the troubles I've had
debugging legal programs because some turkey wrote an optimizer that
shaves a few microseconds off, but screws up in some rare case that I'm
just lucky enought to hit.

By the way, when I first ran into the problem I posted with DO loops in
FORTRAN, I considered it to be a bug.  Now it's been documented (for at
least 10 years), but I still regard it as a bug.  It's simply too outrageous
for a statement like

	IF (Y .GT. 0) X(I) = SQRT(Y)

to ever try to take the square root of a negative for me to accept it.

Unfortunately, too many (read: every one I've ever dealt with) computer
manufacturers thing that it's legitimate for their software to do all
kinds of outrageous things if they just bury a sentence about it in the
documentation.  Another goody from IBM, this time from the PL/I Programmer's
Guide:

	The use of bit strings in a multiprocessing environment may,
	occasionally, lead to incorrect results.
-- 

	Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550