Mail Archives: djgpp-workers/2000/03/26/11:51:03
On 25 Mar 00, at 23:26, Eli Zaretskii wrote:
> > > static const unsigned short pos_nanshort[] = {0,0,0,1,0x7fff,0};
> > > static const unsigned short neg_nanshort[] = {0,0,0,1,0xffff,0};
As I learned from Eli, Hans-Bernhard, and the Intel manual these are
not "normal" NaNs but pseudo NaNs. I admit my error. I was not aware,
that even extended IEEE 754 format NaNs and Infinities must have the
most significant mantiassa bit set. (And I still wonder about the
intention of this requirement.)
> >
> > 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.
Then, I don't understand, how I should read your bit patterns.
There are only 16 hexadecimal digitits in your examples, while
a long double should have 16 hex digits for the significand, and
four hexdigits, when combining sign and exponent. Perhaps I need some
glasses.
> 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.
In the Intel manual, Table 7-12, (unsupported extended real
encodings) the biased exponent field for unnormals is given as:
11..10
.
00..01
So, 00..00 and 11..11 are excluded.
> 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.
Yes. My example numbers should never be used. But you have to print
something for them anyway, when they are produced by buggy code.
- Raw text -