Path: utzoo!utgpu!water!watmath!clyde!ima!compilers-sender From: wendyt@pyrps5.pyramid.com (Wendy Thrash) Newsgroups: comp.compilers Subject: Re: Optimizations and Language Definitions Message-ID: <2671@ima.ima.isc.com> Date: 20 Sep 88 23:09:26 GMT Sender: compilers-sender@ima.ima.isc.com Reply-To: wendyt@pyrps5.pyramid.com (Wendy Thrash) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 54 Approved: compilers@ima.UUCP Me: >> [I]f I write y = (x - 1.0) + 1.0; there's a very good reason for it, >> and I don't want the compiler to mess it up, no matter what it is allowed >> to do by the language definition. Please, at least honor my parentheses >> in floating-point computations. Dale Worley: >Oh, God! Please, please, please, never say "I don't care what the >language definition says"! You will unleash a horde of one hundred >thousand dweebs who say "it works on *my* compiler, it should work >everywhere!". That is precisely what I would like to do: unleash a horde of one hundred thousand numerical analysts clamoring for a useful programming language; then the next ANSI committee will have a harder time shouting them down. >The only way to control this chaos is to >*absolutely* respect the language definition, both in terms of what it >guarantees, and in terms of what it does *not* guarantee. We could debate this point, but perhaps we'd best do so in talk.origins. I am an evolutionist; I believe that computer languages evolve. I believe that this is a good thing. Others may disagree. Certainly I'd be greatly distressed if I were required to make *(a+1) be the same as b after an int a,b; declaration, but if it would sell a hundred thousand systems I'd find a way to do it. (I'd also make it an option, since it would absolutely kill us on performance. :-) ) Six or eight years ago I held a hard line against extensions; if it wasn't in the standard, I wouldn't do it, and I'd say "dweeb" or worse to anyone who thought that because his compiler did it, mine should. I've mellowed with age, and I find that many of those dweebs out there actually know more about their needs than I do. By the way, it seems to me that ANSI C provides a way to do what I want and stay within the language definition. Something like #pragma associativity off could disable the use of the associativity by the compiler for floating-point computations, n'est-ce pas? [No, pragmas aren't supposed to change the semantics of code. It seems to me, though, that since floating point operations are not in general associative the "as if" rule would rule out rearranging such operations except in the rare case where the compiler can prove that the results are the same. If someone who really knows the proposed standard can comment on this, I'd be pleased to hear about it, otherwise I consider this topic wrapped up -- it's getting too close to theology. I wouldn't mind some suggestions about what sorts of things to provide in a language for numerical analysis, whether a superset of C or anything else. -John] [From wendyt@pyrps5.pyramid.com (Wendy Thrash)] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request