X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 22 Mar 2000 13:30:44 +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 AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <Pine.SUN.3.91.1000322102403.17945D-100000@is>
Message-ID: <Pine.LNX.4.10.10003221305060.29657-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 Wed, 22 Mar 2000, Eli Zaretskii wrote:
> On Mon, 20 Mar 2000, Hans-Bernhard Broeker wrote:

> > > whose result should be a QNaN, i.e. either with the sign bit reset or 
> > > with a mantissa that doesn't fit the real indefinite description.

> > It's not just 'a QNaN'. You get 'the QNaN with the bigger significand'
> > (i.e. mantissa), according to my book.
> 
> Yes, but in this case the mantissas were identical.

That figures. The tricky part would be: what do you get if you put in two
different NaN bit patterns (one of them could be 'real indefinite', the
other some other on), with any combination of sign bits: does the sign bit
of one of the input NaN get propagated to the result? If so which one? Or
are the sign bits treated as usual?

> > Thinking about, this seems to imply
> > that the sign bit of the QNaN with the (absolutely) bigger significand is
> > just copied as-is.
> 
> How do you deduce that?  The manual keeps suspicious silence about the 
> sign bit.

No strong deduction, that's why I said 'it seems to imply'. But it does
say that 'the NaN' with the bigger significand is output as the result. As
the sign bit can (arguably) be said to be part of 'the NaN', it would be
copied, too. At least, I have found nothing in the book to tell me
otherwise...

A little experimentation with gcc-2.7.2 on a Linux box showed this 
to hold: the sign bit of the result is copied over from the NaN with
the bigger significand. The test program, for reference:

#include <stdio.h>
#include <math.h>

typedef union float_trick {
  unsigned short words[5];
  long double value;
} float_trick;

int main(void)
{
   int i;
   float_trick ft1 = {{0,0,0,0xc000,0xffff}};
   float_trick ft2 = {{0,0,0,0xca00,0xffff}};
   float_trick res;

   res.value = ft1.value * ft2.value;
      
   printf("isnan(%Lf)=%d\nWords:", res.value, isnan(res.value));
   for (i=0; i<5; i++) {
      printf("%x ", res.words[i]);
   }
   printf("\n");
   return 0;
}

No matter what I put in for the sign bit of 'ft2' (the NaN with the bigger
mantissa), that was the sign bit of the output NaN. I've looked in the
assembly code to verify that gcc does not introduce any black magic to
achieve that, either: it just fldt's the bits into the FPU, fmulp
%st,%st(1), and fstpt back into memory for printing.

I haven't cross-checked with gcc-2.95.2, for lack of a machine in
reach to do it on (my machine at home was wedged completely by 
M$ Office, last night :-()

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