Mail Archives: djgpp-workers/2000/04/02/04:35:40
On Sun, 26 Mar 2000, Dieter Buerssner wrote:
> 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.)
I'm guessing that Intel didn't want the infinities and quiet NaNs to
produce the denormal exceptions, so they defined them all with the
integer bit set.
> > > 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.
Sorry, I misunderstood you. I thought you were talking about the last
(6th) element of the array in *your* code, not the missing 5th word in
*my* code. I indeed erroneously omitted the 5th word.
> > 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.
Yes, the Intel manual calls them pseudo-NaNs.
> Yes. My example numbers should never be used. But you have to print
> something for them anyway, when they are produced by buggy code.
I suggest "unnormal", like it already does.
- Raw text -