X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Thu, 16 Mar 2000 14:32:08 +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.1000316114227.3117D-100000@is>
Message-ID: <Pine.LNX.4.10.10003161358440.22148-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 Thu, 16 Mar 2000, Eli Zaretskii wrote:

> 
> On Wed, 15 Mar 2000, Hans-Bernhard Broeker wrote:
> 
> > Unnormalized numbers other than the denormals
> > shouldn't usually need any special treatment at all.  If memory serves,
> > they're auto-normalized on reading into the FPU.
> 
> Not true.  You can easily write a simple test program which will show
> the facts.

I looked into the literature, as promised, and find you're right:
denormals have their own exception code, but unnormals are treated exactly
like (signalling) NaN's: 'invalid operation' exception, TAG-code of
the FPU register is '10' (binary), like with NaNs. 

So the only test that would work to check if a given number is an
unnormal, rather than a signalling NaN would have to operate outside the
FPU, by checking bit patterns directly:

	if (MSB(mantissa)==0) {
          if (exponent == max_exponent)
             it's a signalling NaN  /* nan, to C99 nomenclature */
          else if (exponent == min_exponent)
             it's a denormal        /* subnormal, to C99 */
          else
             it's an unnormal       /* undefined in C99 */
        }

I think we'll have to differentiate between what the IEEE standard(s) call
a NaN, and what appears as one in the C99 standard. The C standard doesn't
allow us to introduce another class of fp numbers besides 'normal',
'subnormal', 'infinity', 'nan' and 'zero', it seems. It does not specify
any type of behaviour for either signalling NaNs or unnormals, not even if
we choose to make our implementation use '#define __STDC_IEC_559__ 1'
mode.

Thus, it's our choice what behaviour signalling NaNs and unnormals
should cause. Not only in printf(), but everywhere. I see two
possibilities, roughly:

1) provide a default SIGFPE handler for the 'inavlid operation' excetion
that reads the offending FPU register and 'repairs' it. It would convert a
signalling NaN to a quiet NaN, and an unnormal to a normal (or denormal,
where necessary), respectively. This might be a slow method, but it should
be possible.

2) define signalling NaNs and unnormals to belong to class 'nan' of the C
standard. AFAICS, this should fix everything quite nicely.

The basic underlying problem of this has been well stated by you, Eli: The
only way to *get* sNaN or unnormal bit patterns, in the first place,
already crossed the 'undefined behaviour' border earlier, when data was
casted or union-tricked into a long double value from some other type.

So the current behaviour would also be allowed by the standard. Just let
such programs get what they asked for: a crash of the program by SIGFPE.

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