IEEE 754 extended precision expression evaluation - we did it

[uunet!cup.portal.com!PLS]

I remember fighting with exactly this problem when I was working on Fortran
compilers for Honeywell mainframes. This architecture does its floating point
calculations in an overlength register.

The solutions we came up with, in order of ease of implementation, are

1. Any code that uses the .eq. operator between two floating point values
   is broken, and can not be made to give predictable results. We added
   a compiler warning to this effect.

2. We thought about adding instructions to round the register value to 
   storage precision, but decided not to slow down everyone's program just
   to save some people from themselves. See #1.

3. We decided that the ultimate problem was with the compare instruction.
   On this machine, all compares were register vs. storage. We decided that
   the compare instruction should round the register to storage precision
   before doing the compare.

4. In the context of new hardware, I think the solution is to recognize
   that the compare instruction must know the precision of the operands
   being compared and must round and operands that are of wider precision.
   Thus any compare between a full length register and a narrower storage
   location must internally round the register value before doing the
   compare. Register to register compares must specify the precision as
   part of the op code and must round both operands to that precision before
   comparing.

This rounding, of course, must always produce the same result as the rounding
that a store would do.

This would solve your problem with your example. I persist in thinking that th
source code is broken, though.
page

    ++PLS