Satan loves extended precision

[Samuel A. Figueroa]

In a previous message, Patrice L. Roussel <uunet!ichips.intel.com!prousselauunet.uu.net> wrote:
  >On Thu, 19 Jan 95 03:12:39 EST  uunet!f.gp.cs.cmu.edu!jonathan_r_shewchukauunet.uu.net wrote:
  >> However, it is possible for a chip that stores 80-bit extended precision
  >> numbers internally to save a little extra state to ensure that when a
  >> number is stored to memory, it is rounded just as it would have if it had
  >> originally been rounded to 53 bits, thereby complying with the IEEE 754
  >> standard.  Does the 486DX do this?  If not, is there any way to correctly
  >> simulate 53-bit rounding - preferably using portable C code?  Does the
  >> Pentium (or other chips) have this flaw as well?
  >				^^^^^^^^^^^^^^^^^
  >This is not a flaw. The x86 FP architecture offers more than what IEEE
  >does. The reason why overflow/underflow thresholds do not depend on the
  >PC value (they are set to double extended), is to allow people to do
  >such things as calculating the length of a representable vector without
  >any overflow/underflow during the computation of the squares.

I thought I would just point out that the x86's behavior in this respect is
fully conformant to the IEEE Standard.  That is, the IEEE Standard allows a
conformant floating-point engine to normally produce extended precision
results, provided the user can set a mode to make the engine produce a
correctly rounded single or double precision result.  Furthermore, what
happens if the result is beyond the over/underflow threshold for single or
double precision is not fully specified.

I would characterize this area of the Standard as being somewhat unclear.
For one, it's not clear exactly which operations this mode is supposed to
affect.  It's supposed to affect the arithmetic operations, but for some
reason, I'm not sure I could come up with a list of all the arithmetic
operations.  I'm sure they include addition, subtraction, multiplication,
division, and square root, but are there others?

Also, is the rounding control mode supposed to be static or dynamic?  On the
RS/6000, the rounding control mode is static, but on the x86 and 68k it is
dynamic.  One could interpret the IEEE Standard as saying that the rounding
control mode must be dynamic, since the definition of the word "mode" implies
this.  On the other hand, one could also interpret the IEEE Standard as saying
that this mode does not need to be dynamic, since if this mode is static in
some floating-point architecture, one can claim that one's engine does not
normally produce results to double or extended precision.  Rather, one's
implementation of the Standard requires a combination of hardware and software.
Here's how it could work: One can say that one's engine doesn't have any
registers - all operands are stored in memory.  In order to perform, say, a
single precision operation, one loads the operands from memory, sets the
rounding control mode (which is static) to single precision, performs the
operation producing a result in either double or extended precision format
(depending on the floating-point architecture), then stores the result to
memory in single precision format.

Now, I'm not saying anyone would want to do this, only that the IEEE Standard
seems to require that the rounding control mode be dynamic, but, if interpreted
according to the letter of the law, in reality it doesn't.  So, even though the
rounding control mode on the RS/6000 is static, it is still compatible with the
IEEE Standard in this respect.

Anyway, if anyone responds to this, he/she probably ought to change the subject
line.