Re: Optimizations and Language Definitions

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)]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.