Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!wjh12!talcott!harvard!macrakis From: macrakis@harvard.ARPA (Stavros Macrakis) Newsgroups: net.unix-wizards,net.lang Subject: Re: Optimization and language level Message-ID: <227@harvard.ARPA> Date: Wed, 19-Dec-84 19:30:11 EST Article-I.D.: harvard.227 Posted: Wed Dec 19 19:30:11 1984 Date-Received: Fri, 21-Dec-84 01:37:13 EST References: <6599@brl-tgr.ARPA> <979@opus.UUCP> Organization: Aiken Computation Laboratory, Harvard Lines: 57 Xref: watmath net.unix-wizards:11158 net.lang:1150 > > > FORTRAN is so crippled in...express[ing] what's "really going on" in its > > > problem domain that a decent...compiler has to do a lot of optimization. > > Compilers that optimize code can break programs regardless of language.... > Not quite fair to compilers. If optimizing breaks programs which conform > to the language definition, the optimizer is broken. If optimizing breaks What does it mean to 'break' a program.... It's taken several decades to realize that clean semantics in a language is usually more important than easy or straightforward compilation. But then, perhaps I shouldn't say 'realize' as it appears that many partisans of a (dare I mention it?) well-known PDP-7 operating system still cling tenaciously to its systems programming language's virtual lack of implementation-independent semantics.... In any case, Fortran and C are relics of those long-forgotten and dark ages. Not to say that C doesn't have some strong points in applications where one would otherwise be forced to resort to an even lower-level assembler (really, now, is C much higher level than assembly language?). So we come to optimization. If we see the language as simply a way of expressing individual machine operations, then indeed optimization is problematical. In the extreme case, one might be writing a hardware diagnostic where it is important that "if (1+1=2) then x=1" retain the arithmetic and comparison operators rather than just set x to 1. If on the other hand, the language is conceived of as a formal language with a given abstract semantics, then we'd like to minimize the pragmatic considerations which enter into its processing (you can't go too far, or any program which doesn't have any inputs (e.g. calculate pi to 10000 places) could be 'executed' at 'compile' time). The tough engineering decisions come in the language design, where the designer must (usually) trade off precise and clean semantics for efficient processing. Efficiency might be lost by runtime checking, or it might be lost by imposing standard results where this would be expensive to port--consider, e.g., fully specifying floating-point arithmetic. In principle, it is just as clean to leave certain kinds of results unspecified, but in practice, many purposely undefined results are exploited either carelessly or intentionally by programmers (e.g. Fortran does not require reference passage of parameters, but most Fortran programmers seem to assume it). Ada has been criticized for dealing with this phenomenon by distinguishing 'illegal' (must be detected by the processor) from 'erroneous' (might not be) usages. In fact, Ada is only acknowledging existing practice while clarifying its definition. Optimization must not change the meaning of the program. This seems pretty basic. The dispute comes in the word 'meaning'. Is the 'meaning' of '1+1' the same as the meaning of '2'? Is the 'meaning' of 'x+x' the same as that of '2*x'? This all depends on your language. If your language and compiler have both been well engineered (and documented!), the language will let you express your intended meaning conveniently, and the compiler will correctly translate that meaning into good code. If not, good luck! Conclusion: Don't blame the optimizer, blame the language! Stavros Macrakis Harvard