Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ut-ngp.UUCP Path: utzoo!utcsrgv!garfield!philabs!cmcl2!seismo!ut-sally!ut-ngp!oacb2 From: oacb2@ut-ngp.UUCP (oacb2) Newsgroups: net.unix-wizards,net.lang Subject: Re: smart compilers Message-ID: <1151@ut-ngp.UUCP> Date: Sat, 22-Dec-84 18:14:30 EST Article-I.D.: ut-ngp.1151 Posted: Sat Dec 22 18:14:30 1984 Date-Received: Mon, 24-Dec-84 15:42:18 EST References: <6599@brl-tgr.ARPA> <979@opus.UUCP> <6831@watdaisy.UUCP> Organization: U.Texas Computation Center, Austin, Texas Lines: 53 > 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