double rounding in x86

[Samuel A. Figueroa]

In a previous message, Tom.Lynchaamd.com (Tom Lynch) writes:
  >  moshier:
  >  I have heard about that in connection with the 8087 and 80287, but
  >  thought it was supposedly fixed in later models.  Could you please
  >  send me a specific numerical case, if you have one handy?

I don't know what "that" is referring to, but it could be to the fact that the
8087 and 80287 supported unnormalized numbers, a feature removed from the final
version of the IEEE Standard.

  >It hasn't been "fixed".  There are many cases, in addition to the
  >one I gave originally.
  >   1) Any calculation which has an intermediate value which is
  >      larger than the double/single exponent can represent, but still within
  >      range for the double extended exponent - while the precision 
  >      control field is set to double/single.  
  >      The IEEE conformant** arithmetic will produce an infinity, the
  >      x86 machine will not.
  >      ** there is a footnote in the IEEE spec which "allows" for extended
  >      range.  It is not clear what the meaning of the foot notes is, but
  >      this is at least arguably compliant.

I think, taking into consideration the entire content of the Standard, that
it would be difficult to argue that if a footnote implies that something is
allowed, that something is definitely NOT allowed.

  >      However, it certainly causes
  >      one to diverge from the values that would be produced on other
  >      platforms.
  >      It has also been argued that such divergence is immaterial.  I
  >      fail to see a purpose for the standard if this is the case.

Perhaps this only means that if you were to come up with a standard for
floating-point arithmetic, you would not take the same approach that was taken
in developing the IEEE Standard.  Again, if convergence among different plat-
forms had been a goal, the Standard would have been written differently.

  >   ...
  >   3) The case that was brought out by Paranoia (described earlier):
  >      A small value rounds to a value half way between two representable
  >      values in the reduced exponent range.  A store is done, hence
  >      a second rounding.  Double rounding of a result is certainly not
  >      IEEE 754 compliant.
  >      Some have argued that this memory value is not a *result*.  I
  >      do not accept this argument, as memory values are operands for
  >      further calculation.  Obviously they are results.

If you want to use your notion of what a result is, you either have to modify
the Standard, or else you have to qualify what you write by saying that your
floating-point arithmetic engine is implemented as a combination of hardware
and software (the latter including the language translator you are using),
that results of operations are (conceptually) never stored in registers,
only in memory, and that that combination of hardware and software does not
conform to the IEEE Standard.  I believe it is inaccurate to say that an
implementation of the x86 architecture, in absence of the software you
describe, does not conform to the IEEE Standard, at least in the area of how
the basic arithmetic operations are performed.  Put another way, I'm sure you
can come up with an assembly language translation of Paranoia such that, when
executed on an Intel x86 processor, the test you mention above will be passed.
Finally, Paranoia is NOT a program designed to verify whether a floating-
point engine fully conforms to the IEEE Standard.  Of course, that doesn't
mean that this program cannot be very useful for other purposes (such as
whether your combination of hardware and language translator is adequate for
your purposes).

  >      It has also been argued that memory versus local stack is a 
  >      compiler issues - and the standard doesn't deal with compiler
  >      issues.  I find this argument has a conclusion that doesn't 
  >      follow from the supposition.  It is true that the memory versus
  >      stack isn't an issue according to the standard.  And I would 
  >      conclude therefore, it should work both ways - if it is used
  >      both ways.  It is immaterial where the code and operands come
  >      from.  Yes, this is not a compiler issue.

Again, you have to be careful how you define the extent which your floating-
point arithmetic engine encompasses.  Which hardware and which software makes
up that engine?

  >      Yet another argument has been, who really cares, it is close enough,
  >      there is a huge user base, and PC code isn't numerical intensive
  >      anyway.  I disagree with this on the basis that this that compliance
  >      is a technical issues, so marketing studies and forcasts irrelevant.
  >      (One may decide that the IEEE std. 754 is not appropriate to there
  >      application, but one can not decide they are compliant because the
  >      it is not "important").

I'll let someone else tackle this, as I agree with Mr. Lynch here.  (Maybe
there is still hope that Mr. Lynch and I might still be able to get along. :-)
But I hope my points of disagreement are clearly explained.  I think it would
be helpful if the IEEE Standard were clearer in some areas.

- Sam Figueroa (figueroaacs.nyu.edu)