Re: Making Lemonade (Floating-point format changes)

MitchAlsup1 wrote:

  Imagine, instead, if IEEE 754 had defined positive underflow with the
result of positive tiny, negative underflow with negative tiny,
positive overflow with positive infinity-epsilon and negative
overflow with negative infinity+epsilon.
 Here, the fact overflow or underflow happened is recorded in the
result, and these results remain identifiable from real infinities
or real zeros.
 But that ship sailed 50 years ago.

If an overflow occurs and that exception is masked, x86 returns a
value of either +-largest finite number (LFN) or +-infinity (INF),
depending on the rounding mode.
(vol-1 Arch manual, section 4.9.1.4, Numeric Overflow Exception,
Table 4-10. Masked Responses to Numeric Overflow)

Rounding_Mode Sign_of_Result Result
------------- -------------- -------------------------------
To nearest    +              +∞
               –              –∞
Toward –∞     +              Largest finite positive number
               –              –∞
Toward +∞     +              +∞
               –              Largest finite negative number
Toward zero   +              Largest finite positive number
               –              Largest finite negative number

The difference seems to be that INF is a sticky overflow, LFN is not.
Would this not satisfy everyone?

The problem is that it requires diddling the control register to change
the round mode, as opposed to round mode on each float instruction.
Or maybe even the LFN/INF overflow choice should be a separate option
independent of round control bits.