Date: Sat, 25 Mar 2000 23:26:50 -0500 Message-Id: <200003260426.XAA26111@mescaline.gnu.org> From: Eli Zaretskii To: buers AT gmx DOT de CC: djgpp-workers AT delorie DOT com In-reply-to: <200003221404.QAA20523@is.elta.co.il> (buers@gmx.de) Subject: Re: Unnormals??? References: <200003201825 DOT UAA28340 AT is DOT elta DOT co DOT il> <200003221404 DOT QAA20523 AT is DOT elta DOT co DOT il> 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 > > 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 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. I actually ran the program inside GDB and looked at the FP registers. The debugger sems to confirm my understanding of how these numbers are loaded into the FPU. If there's something I'm missing, please expain. > These are indeed unnormals: their mantissa has a zero MSB. 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. > 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 think it should, and it also did this before the unnormal check was added. 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.