Re: Warning: Flame Bait

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.849366601@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>For example, all DEC Alpha's and the high end MIPS chip (R10000) are both
>weird by this definition, because they do not quite implement the whole of
>the IEEE floating-point standard. If you are serious about Java requiring
>strict adherence to the IEEE standard, then it will be impossible in either
>of these cases to provide this strict adherence without a huge loss of
>efficiency (just try running your favorite Fortran codes on a DEC Alpha
>in strict IEEE mode, and you will see what I mean). 

Interesting.  I guess it remains to be seen how seriously Java compiler
writers take the standard.  Ada 83 compiler writers have a history of
obeying the letter of the law (especially when pushed by the ACVC).
Sometimes even in those rare circumstances where the letter of the law
damages their customers.  I'll bet that Java a compiler writer could get
away with using the machine arithmetic, if it's "pretty close" to strict
IEEE.  (Of course, if the machine isn't IEEE at all, Java is stuck with
software floating point emulation.  I guess that's what you want for
applets distributed over the internet, but not for high performance
numerics stuff.)

Note also that many of the issues we're talking about have nothing to do
with particular machines.  For example, order of parameter evaluation.
Ada says "arbitrary order", in the hopes that compilers can generate
more efficient code.  Java says "left to right", putting portability
ahead of efficiency.  Maybe the Java designers would argue that the
efficiency hit is small, or maybe they would argue that portability is
essential, and efficiency less important.

(By the way, there are cases in Ada 95 (not Ada 83) where the parameters
can NOT be evaluated left to right!)

>You have to know a LOT to avoid such mistakes. My guess is that the folks
>at Sun who specified IEEE floating-point were simply unaware of the
>consequences (it is possible that this was a subtle way of designing a
>language more amenable to Sun than to SGI or DEC, but I doubt it was
>well enough informed to have been so clever :-)

Really?  I suspect they knew what they were doing.

- Bob