underflow definition

[David Hough]

No sooner had I read Jim Valerio's contribution than I got a phone call from
a guy who had figured out that I had forgotten the definition of underflow
in the IEEE standard (754 or 854).

The point in question is exemplified by converting .ffffff * 2**-126 to
single precision storage format.  The correct untrapped numerical result
is 1.0 * 2**-126 or .fffffe * 2**-126 depending on rounding mode.
There is no question about this.  The question is whether underflow is
signalled.

If you claim to detect underflow before rounding, the answer is 
unequivocally "yes".  What about if you claim to detect underflow
after rounding?  Is it after rounding to storage format (1.0 * 2**-126,
no underflow) or to storage format precision but unbounded exponent
(.ffffff * 2**-126, underflow).  Turns out I had thought it was
the former, but 754 and 854 are quite explicit: the latter.

The IEEE test vectors for multiplication support this view, I think:

! Underflow, barely.
2*      0<     Ep1d1  1m1   xu      Ed1
2*      0<     -Ep1d1  -1m1   xu      Ed1
2*      0>     -Ep1d1  1m1   xu     -Ed1
2*      >=     Ep1d1   1m1   xw      E
2*      <=     Ep1d1  -1m1   xw     -E

It looks like I didn't do it right in the Sun-4 kernel:

        case fp_normal:
                fpu_rightshift(pu, 113-24);
                pu->exponent += SINGLE_BIAS;
                if (pu->exponent <= 0) {   
                        px->exponent = 0;
                        fpu_rightshift(pu, 1 - pu->exponent);
                        round(pu);
                        if (pu->significand[3] == 0x800000) {   /* rounded
                                                                 * back up to
                                                                 * normal */
                                px->exponent = 1;
                                px->significand = 0;
                                return;
                        }
                        if (_fp_current_exceptions & (1 << fp_inexact))
                                fpu_set_exception(fp_underflow);
                        else if (fp_fsrtem & (1<<fp_underflow))
                                fpu_set_exception(fp_underflow);
                        px->significand = 0x7fffff & pu->significand[3];
                        return;
                }

Looks to me like underflow signalled after rounding to storage format.
Time for a bug report?
The IEEE calculator looks like this:

unnormkind, normkind : begin
if x.exponent <= mines then begin (* Underflow.  *)
if underfl in fpstatus.trap then begin (* Trap enabled.  *)
setex ( underfl ) ;
x.exponent := x.exponent + 192 ;
if (  x.exponent <= mines) or (not x.significand[0])
then begin (* Severe underfl.  *)
makenan(nanresult,x) ;
end ;
end
else begin (* Trap disabled.  *)
right( x, mines + 1 - x.exponent ) ;
x.exponent := mines+1 ;
roundkcs( x, fpstatus.mode.round, sprec ) ;
if inxact in fpstatus.curexcep  then setex ( underfl ) ; (* Signal.  *)
end ;
end ;
 
This looks like underflow signaled before rounding.

Of course this is almost inconsequential.  No reasonable program would
do anything different if an untrapped underflow was or was not detected
associated with a minimum normalized result.  But diagnostic programs
are bedeviled by the uncertainty as they try to distinguish incorrect 
implementations from
correct but different standard-conforming underflow implementations.