Path: utzoo!attcan!uunet!lll-winken!maddog!brooks
From: brooks@maddog.llnl.gov (Eugene D. Brooks III)
Newsgroups: comp.arch
Subject: Re: Standard Un*x H/W architecture
Message-ID: <10298@lll-winken.llnl.gov>
Date: 19 Jul 88 20:51:33 GMT
References: <980@garth.UUCP> <76700037@p.cs.uiuc.edu> <12005@ames.arc.nasa.gov>
Sender: usenet@lll-winken.llnl.gov
Reply-To: brooks@maddog.UUCP (Eugene D. Brooks III)
Organization: Lawrence Livermore National Laboratory
Lines: 19

In article <12005@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes:
>IF a particular program gets correct answers
>using the IEEE standard, and incorrect answers using a less robust
>format such as Cray's current format, is it better to get the
>wrong answer 10% faster?  This is, in fact, the problem that
I have a lot of experience dealing with porting codes which run
on 64 bit IEEE on UNIX boxes, 64 bit "claimed to be IEEE"
UNIX boxes(don't ask me which ones these are, I don't want a
confrontation with their manufacturers), and 64 bit Cray format.
In general it is nice to have a code run and produce "exactly the same"
bitwise results everywhere and I have had plenty of sensitivitys
to the differences in the floating point surface.  Anytime a
sensitivity to the arithmetic surfaced I was usually glad that
it did as is meant that the fact that I was "on the ragged edge"
was being detected by the "machine with the bad floating" point.
This affords me the chance to move away from the ragged edge by
fixing the code.  Any machine with IEEE arithmetic outght to have
a "round inward an extra couple of bits" option for "ragged edge"
detection.  If it happens to result in 10% faster execution time
so much the better.