Mail Archives: djgpp-workers/2000/03/26/00:31:18
> > static const unsigned short pos_nanshort[] = {0,0,0,1,0x7fff,0};
> > static const unsigned short neg_nanshort[] = {0,0,0,1,0xffff,0};
>
> When converted to a long double, these two have the following bit
> patterns:
>
> pos_nanshort = 7fff 0001 0000 0000
> neg_nanshort = ffff 0001 0000 0000
Have your forgotten 0000 at the end of the previous two lines?
No, I haven't, but I don't see why do they matter. A long double
number is only 10 bytes long.
I actually ran the program inside GDB and looked at the FP registers.
The debugger sems to confirm my understanding of how these numbers are
loaded into the FPU.
If there's something I'm missing, please expain.
> These are indeed unnormals: their mantissa has a zero MSB.
I think, they are not unnormals. I think this discussion has shown,
that unnormals must have a finite exponent.
I don't see the finite exponent requirement in the Intel manual.
> If you wanted _doprnt to support so-called pseudo-NaNs, as described
> in section 7.4.4 of the Intel manual, then we indeed need to reserve
> the 0x7fff exponent for a NaN. But _doprnt currently doesn't support
> pseudo-NaNs (and I'm not sure it should).
I think it should, and it also did this before the unnormal check was
added.
The pseudo-NaNs aren't generated by the FPU, they can be only loaded
there by an application. So it is arguably better to let them stand
out as (potential) bugs, since they cannot possibly serve any useful
purpose.
- Raw text -