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 X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: Unnormals??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.