X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Mon, 20 Mar 2000 17:07:09 +0100 (MET)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: Unnormals???
In-Reply-To: <Pine.SUN.3.91.1000320172540.26722B-100000@is>
Message-ID: <Pine.LNX.4.10.10003201648450.25247-100000@acp3bf>
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 Mon, 20 Mar 2000, Eli Zaretskii wrote:
> On Mon, 20 Mar 2000, Hans-Bernhard Broeker wrote:

> > > > The result of nan(NULL) and/or nan("") should be some 'standard NaN', but
> > > > I object to using the negative 'indefinite real' for that. Its positive
> > > > (but nameless) counterpart would be a good choice.
> > > 
> > > That counterpart does have a name: it's a QNaN.  
> > 
> > No. QNaN is the name of the whole class of quiet NaNs. There are 2^62 of
[...]
> I fail to see the relevance of this.  You said that the real indefinite's 
> counterpart without a sign has no name, to which I replied that it's name
> is "QNaN".  How does it matter that there are many more QNaNs, in 
> addition to this specific one?

A misunderstanding, then. I wanted to express that unlike the special name
of 'real indefinite', the same bit pattern, but with the sign bit unset,
has no special name of its own. Of course both belong to the class of
QNaNs, but I wouldn't say that makes 'QNaN' a 'name' for that single
particular NaN bit pattern. It's a classificaton.

> > There are no 'computations', in that example. the first printf() of
> > sqrt(-1) yields a string. From there on, only conversion functions between
> > character representation and binary floating point format are used.
> 
> Conversions inside strtod involve computations.  

Only if we implement it that way... NaN handling in strtod would be
implemented in terms of bit patterns, I think, not by 'computing'
anything.

> That's what I was 
> referring to.  I don't think you can inject the real indefinite into the 
> FPU and hope that it stays that way throught FP computations.  I assumed 
> that some FP instructions would be used inside strtod, since FP values 
> are returned in FP registers in our ABI.

We can load any NaN we like into an FPU register, be it real indefinite or
whatever. Load/store operations do not raise any exception on QNaN.

Actually, even an SNaN does not generate an exception in some FPU
operations, including FLDT, FXCH, FCHS and FABS (as I just read in the 387
book I have brought in from home). To me, the latter two ('change sign',
and 'absolute') imply that sign in NaN is handled, at least partly, in the
usual way, by the FPU.

The book also says that it should be possible to load a long double SNaN
into the FPU (fldt) without generating an invalid operation exception. So
we *can* pass back arbitrary NaNs via the FPU register.

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