From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,70016ed51014902d X-Google-Attributes: gid103376,public From: Clayton Weaver Subject: Re: IEEE fp & Java Date: 1996/12/02 Message-ID: #1/1 X-Deja-AN: 201851018 sender: news@eskimo.com (News User Id) x-nntp-posting-host: eskimo.com references: <01bbdcb5$7500ab30$24af1486@pc-phw> content-type: TEXT/PLAIN; charset=US-ASCII organization: Eskimo North (206) For-Ever mime-version: 1.0 newsgroups: comp.lang.ada originator: cgweav@eskimo.com Date: 1996-12-02T00:00:00+00:00 List-Id: 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)