double rounding in x86
Samuel A. Figueroa
uunet!SLINKY.CS.NYU.EDU!figueroa
Sat Sep 9 20:48:34 PDT 1995
In a previous message, Tom Lynch (Tom.Lynchaamd.com) writes:
>Please, I am not talking about "my opinion" we are talking about what the
>standard *is*. I do not believe that in an error free calculation there is
>any divergence, with the one exception of having choice of detection of
>underflow. Please list the other:
How about the following:
1) Is the double format or any extended formats (single extended or double
extended) supported? [Actually, (the lack of) support for these formats
would not guarantee divergence.]
2) Exactly what operations are provided? (The Standard does not list precisely
which operations are required.) For example, without any additional soft-
ware, can you take the square root of a single precision number, and get as
a result a correctly rounded single precision number? (This particular
function is NOT required by the Standard, even for those implementations
that are capable of delivering results in the single format, but even if an
implementation of the Standard doesn't provide it, it would be trivial to
implement in most cases, unless the widest supported format is single
extended, and the number of bits in the significand of single extended
numbers is less than 50, including the hidden bit, if any. However, if you
replace "single" with "double" in this example, then you can appreciate why
it's important to know which operations are provided.)
Using just these two items as a starting point, you could come up with a long
list of predicates that you could use to predict what the outcome of a calcula-
tion will be. This is hardly what I would call convergence. In practice, the
goal of convergence is not as hopeless as this discussion implies, but yet if
you consider a long chain of computation, attaining convergence among all IEEE-
conforming implementations is costly.
>My idea of a result, is that value calculated, if you have another, please
>lets see it so that we can judge if it is viable.
My point of disagreement here is that you seem to claim that implementations of
the Standard MUST deliver results to memory, but the Standard does NOT require
this.
>I now assert that arbitrary sequences of x86 instructions should be
>IEEE std. 754 conformant (an opinion), and that this could be very
>easily facilitated. Anyone agree? disagree? I must go to issues
>such as compiler design to justify this contention.
>The way I see it, the exponent range should match the precision
>control field. This would make conformant arithmetic on x86
>implementations faster. Anyone know of any alternatives?
As I have mentioned in other messages, the alternatives I know of degrade
floating-point performance significantly. I don't think one can do better.
Enhancements to the x86 architecture could help tremendously here, and I do
think people have the right to expect these enhanced features. (Just think,
possibly except for speed, the x86 architecture would be the nicest implemen-
tation of the IEEE Standard, because you could get the same answers as in other
IEEE implementations if you wanted to, plus you'd have support for extended
precision in hardware.) However, I don't expect Intel will make the necessary
modifications to the x86 architecture, because I don't think they perceive the
commercial impact of this to be sufficiently significant. So I'm afraid we'll
have to put up with two kinds of implementations of the IEEE Standard that are
significant and slightly different from one another. Perhaps the best solution
would be to rewrite the IEEE Standard in such a way that the x86 architecture
doesn't conform. After all, standards are supposed to be revised every 5 years
I believe. Then, Intel would be coerced to change the x86 architecture.
Though even this would probably not work, because Intel would probably veto
such a standard.
>As a second point of contention, the databooks for the x86 parts
>seem to promise that arbitrary sequences of x86 floating-point instructions
>do perform IEEE std. 754 arithmetic - this promise is wrong.
This may be true, though I haven't read Intel literature with the specific
purpose of trying to see if they promise this. However, I would like to see
an analysis of how beneficial extended precision can be in actual practice,
as compared to the difficulties it brings.
- Sam Figueroa (figueroaacs.nyu.edu)
More information about the Numeric-interest
mailing list