Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!sdd.hp.com!apollo!boundy From: boundy@apollo.hp.com (David Boundy) Newsgroups: comp.arch Subject: Re: IEEE floating point (Goldberg paper) Message-ID: <1991Jun13.144506.14140@apollo.hp.com> Date: 13 Jun 91 14:45:06 GMT References: <9106080100.AA09901@ucbvax.Berkeley.EDU> Sender: boundy@apollo.hp.com (David Boundy) Organization: Compiler geek, Hewlett-Packard Company, Apollo Division - Chelmsford, MA Lines: 66 Nntp-Posting-Host: logos.ch.apollo.hp.com In article <9106080100.AA09901@ucbvax.Berkeley.EDU> James B. Shearer writes: >Perhaps I should have said it is undesirable for a program to behave >differently when compiled with and without optimization regardless >of whether this is technically permitted by the standard. (Actually >I think it would desirable for the standard to exactly specify the >behavior of any legal program but apparently it does not.) An example >may explain why I believe this. Consider an user with a 100000 line >fortran package. It works fine when compiled on other machines (with >and without optimization). It works fine when compiled with your >compiler without optimization. However it fails when compiled with >your compiler with optimization. I believe it will difficult to con- >vince this user that the bug is in his package and not in your compiler >whatever the technical validity of your position. Undesirable, yes. But also unavoidable in a market where performance is what sells machines. ( Correctness, as perceived by the individual programmer, is not allowed to be compromised in the name of performance. ) Langauge standards are contracts between language implementers and language users -- "If you program within these rules, we promise to give you a "correct" rendering into the target instruction set." There are responsibilities for both parties. Just as the programer is allowed to assume that a given set of features will be available and will have certain behaviors, so compiler writers are assured by the standard that no program will ever be presented that does thus-and-so; if a "program" *does* violate the standard, we're allowed to do any bloody thing we like with it ( though we try to find some friendly way of rejecting it... ) Thus, standards do "exactly specify the behavior of any legal program:" that's the defintion of a "legal program." Standards do not, however, try to specify the behavior of an arbitrary collection of characters presented to the compiler, in particular those that Mr. Turing assures us cannot be statically distinguished from legal programs. Note that the quoted paragraph breaks down long before we get to floating point. When the Apollo optimizer is turned all the way up, we take full advantage of freedoms in the standards like order of expression evaluation, that parameters to FORTRAN routines may not overlap each other, etc. Compilers with timid optimizers may accept an illegal program and do what the programmer expects; our speed-hungry-and-language-conforming customers would be upset if we bowed to the pressure to make more conservative assumptions, penalizing their programs, instead of pushing the non-conforming program back as "not a bug". But to narrow back down to floating point, it should be noted that I've never encountered a case of arithmetic that can be done at compile time whose operands are outside the set of normalized, denorms, and zero. In other words, all the compile time arithmetic we currently do is legal under the fortran standard. ( There's the issue that on our 68000 machines, we do arithmetic at compile time in 64 bits, but the same expression unoptimized will be evaluated at run time in 80 bits. Sigh. ) We have a plathora of switches that allow the programmer to tell our compilers how much of the standard they want to violate in their source programs, and how much of the standard they're willing to let the compiler violate in order to speed their programs up. The default, of course, is to force both parties to fully observe the terms of the ANSI contract. -boundless ------------------------------------ The opinions here are mine, not HP's -- but since my opinions find their expression in HP's software, the difference probably isn't practically distinguishable...