Message-Id: <200003261639.LAA10816@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Sun, 26 Mar 2000 16:31:29 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Unnormals???
In-reply-to: <200003260426.XAA26111@mescaline.gnu.org>
References: <200003221404 DOT QAA20523 AT is DOT elta DOT co DOT il> (buers AT gmx DOT de)
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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.