delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/03/22/08:20:30

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 22 Mar 2000 13:50:24 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <Pine.SUN.3.91.1000322102606.17945E-100000@is>
Message-ID: <Pine.LNX.4.10.10003221332180.29657-100000@acp3bf>
MIME-Version: 1.0
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

On Wed, 22 Mar 2000, Eli Zaretskii wrote:
> On Mon, 20 Mar 2000, Dieter Buerssner 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};
> 
> 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
> 
> These are indeed unnormals: their mantissa has a zero MSB.

Funny enough, this turns out to be left out by my book, completely.
Maximum exponent, but no leading 1 bit in the mantissa is not covered by
the table of 387 bit patterns, it seems, nor by the ones for 8087 and
287...

> 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'm almost certain it shouldn't. Pseudo-NaNs are explicitly said in my
book *not* to be supported by the 387, any more. As we don't support
processors earlier than the 387, we don't need, nor want support for
Pseudo-NaNs, I think.  They're one of things that were shoved under the
carpet in the movement from 8087/80287 to 80387, along with Pseudo-Zeroes,
Pseudo-Infinities, and the Unnormals this whole thread began with. The
book says all of this was done by Intel to make 80387 compliant to IEEE
754.

The IEEE standard was, according to the other book I have, originally
inspired quite heavily by Intel's 8087 design, i.e. they proposed their
8087 as a standard, sort of. The standard moved away from some of its
original details, then, so Intel had to move to catch up with it --- thus
the 80387 and its incompatible changes wrt. to the 287.

Now, I've been citing this book of mine all through this discussion,
without giving the proper reference. Let me do it, now. It's

	PC XT AT Numerik Buch
	Klaus-Dieter Thies
	tewi Verlag, Munich, 1989
	ISBN 3-89362-033-8

It's in German, and out of print, I suspect. The other one is by some of
the architects of the 8087, John F. Palmer and Sephen P. Morse. I don't
have the ISBN for that, but it's from the same edition and roughly the
same time as the above. There should be an original English version of it,
too.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019