Re: IEEE fp & Java

[Clayton Weaver <cgweav@eskimo.com>]

On 30 Nov 1996, Robert Dewar wrote:

[snip]
> Bob wonders if Java will be the final nail in the coffin for "weird"
> machines?
 
> The trouble is that when you pin down the semantics as far as Java has,
> then a lot of machines become weird.
 
> 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). 
 
> Now, it is certainly trivially easy when designing a language to make a
> statement that FPT will be exactly IEEE 754, and then congratulate 
> yourself for doing such a splendid job of portability design, but if
> what you have achieved is a design that does not run correctly on the
> machines that people think of as being appropriate for high end fpt
> calculations (Sun is not a big player in this market), then perhaps you
> have not done such a great job after all.
 
> 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 :-)
 
Wasn't there a long cross-posted thread back in winter '93-'94 about an
ambiguity in the IEEE fp standard that left parts of the standard
implementation-defined re: rounding intermediate results? I don't recall
the details, perhaps someone else reading here does. Was that ambiguity
a factor in the Alpha and Mips fp designs?

[etc]

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)