reproducibility of tininess detection for binary formats

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

David Hough wrote:
> But the first one depends only on the magnitude of the unrounded exact
> result.  The second one also depends on the current rounding mode.
> Neither one will satisfy everybody all the time, but I prefer the
> first because it's easier to undo an unwanted exception when it is
> signaled than to test for a unsignaled exception on every operation
> where it might have been signaled.

[Here, the first is "detect tininess before rounding"]

I think you got it backwards.  If you want "before rounding" semantics
as you say, but the machine detects "after rounding", there won't be any
unwanted exceptions to undo.  Instead, Nmin results have to be checked
to see whether a delayed exception needs to be raised explicitly.  This
is also what I want, but P754-150 currently demands the opposite.

Providing "after rounding" semantics when the hardware detects tininess
before rounding does require undoing unwanted exceptions.  This is not
as easy as it seems, unless exceptions always trap in a restartable
manner.  It's only in that case that the native underflow handler could
be taught to resume quietly when the result was +-Nmin -- and then only
if trap handling of an exception does NOT implicitly set the summary flag.
So IBM's mainframes (z) could do this, but PowerPC (p) could not.  I don't
know what other architectures do in this regard.

If traps are not desirable, or restartable traps are not available or
affordable,  every susceptible operation must be followed by a check,
just as in the emulation of "before" semantics when the hardware detects
"after".  That's because the evidence (a result of Nmin) will be gone if
the program only depends on detecting summary underflow.

This checking is however worse than the checking that is needed to do
emulation in the other direction, because it is necessary to keep track
of flags before the operation, in order to undo an unwanted underflow
indication.  Two code paths are needed: if underflow is already set, we
have the easy case (no aftercheck required), otherwise do the operation
and check if underflow has to be undone.  That branch may go either way,
though it will probably be easy to predict after the first occurrence.

If underflow traps are intended, but restartable traps are not available
or affordable, we have the worst of the combinations, as the trap must be
disabled (since an unwanted one could not be undone), and then simulated
if actually warranted.

At this point I'm not sure whether you agree or disagree with the current
P754-150 proposal in clause 11, page 60 line 33.

Michel.
Sent: 2007-10-15 00:02:19 UTC