[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Exponent-adjustment indication for trapped over/under-flow



The new Trap handling in sections 8.2 and 8.3 proposes that an
exponent-adjustment number be returned as a positive integer, to be
added to or subtracted from the result exponent in order to recover
the excessive exponent that triggered overflow or underflow.  This
requires knowing whether the trap was triggered by overflow or by
underflow.  In most contexts this information is readily available
from the required IEEE exception status flags.

Those flags are however sticky, so a trap handler might be faced
with both Overflow and Underflow indicated.  There may of course
be an explicit code that indicates the type of the last interrupt,
so that should not be a problem.

Nevertheless, I can imagine situations where looking up the status
information might be inconvenient.  In that case, a *signed* exponent
adjustment factor might be more useful:  negative for underflow,
positive for overflow, and zero in all other cases.  The adjustment
factor could then be blindly added to the result exponent in order
to recover the original (possibly excessive) exponent.

Was there a particular reason for chosing an unsigned adjustment?


A second concern is with the deliberate deviation from the 1985
exponent-wrap rule, which some manufacturers (including IBM) have
implemented.  Having studied mixed-size radix conversion issues,
I'm fully aware of the fact that the old rule cannot cover all
cases.  However, the new rule could accomodate the old one, by
permitting an exponent-adjustment factor that is a multiple of
some (perhaps format-dependent) adjustment increment.  The existing
implementations would then be conforming, because the adjustment
number could be considered "given to the trap handler" by the fact
that it can be derived from the context (i.e. operand size).

Michel.


Sent: 2006-02-07 23:34:58 UTC

754 | revision | FAQ | references | list archive