From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCTJS-0001BE-15 for qemu-devel@nongnu.org; Wed, 20 Apr 2011 05:03:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCTJP-0001Ys-VL for qemu-devel@nongnu.org; Wed, 20 Apr 2011 05:03:05 -0400 Received: from hall.aurel32.net ([88.191.126.93]:38575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCTJP-0001Xk-Qa for qemu-devel@nongnu.org; Wed, 20 Apr 2011 05:03:03 -0400 Date: Wed, 20 Apr 2011 11:02:44 +0200 From: Aurelien Jarno Message-ID: <20110420090243.GA6388@volta.aurel32.net> References: <1303160412-8107-1-git-send-email-aurelien@aurel32.net> <1303160412-8107-2-git-send-email-aurelien@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 01/20] softfloat: fix floatx80 handling of NaN List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org On Tue, Apr 19, 2011 at 11:53:50AM +0100, Peter Maydell wrote: > On 18 April 2011 21:59, Aurelien Jarno wrote: > > The floatx80 format uses an explicit bit that should be taken into account > > when converting to and from commonNaN format. > > > > When converting to commonNaN, the explicit bit should be removed if it is > > a 1, and a default NaN should be used if it is 0. > > > > When converting from commonNan, the explicit bit should be added. > > > > Signed-off-by: Aurelien Jarno > > --- > >  fpu/softfloat-specialize.h |   19 +++++++++++++------ > >  1 files changed, 13 insertions(+), 6 deletions(-) > > > > diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h > > index b110187..fb2b5b4 100644 > > --- a/fpu/softfloat-specialize.h > > +++ b/fpu/softfloat-specialize.h > > @@ -603,9 +603,15 @@ static commonNaNT floatx80ToCommonNaN( floatx80 a STATUS_PARAM) > >     commonNaNT z; > > > >     if ( floatx80_is_signaling_nan( a ) ) float_raise( float_flag_invalid STATUS_VAR); > > -    z.sign = a.high>>15; > > -    z.low = 0; > > -    z.high = a.low; > > +    if ( a.low >> 63 ) { > > +        z.sign = a.high >> 15; > > +        z.low = 0; > > +        z.high = a.low << 1; > > +    } else { > > +        z.sign = floatx80_default_nan_high >> 15; > > +        z.low = 0; > > +        z.high = floatx80_default_nan_low << 1; > > +    } > >     return z; > >  } > > The intel manuals don't seem to define what a number with non-zero exponent > field but explicit bit clear actually means. Presumably this (generate a > default NaN) is what the hardware does if you try to convert such a thing > to float64? I tested that on my hardware, on an Intel CPU, and it behaves like that. > > @@ -624,10 +630,11 @@ static floatx80 commonNaNToFloatx80( commonNaNT a STATUS_PARAM) > >         return z; > >     } > > > > -    if (a.high) > > -        z.low = a.high; > > -    else > > +    if (a.high) { > > +        z.low = LIT64( 0x8000000000000000 ) | a.high >> 1; > > +    } else { > >         z.low = floatx80_default_nan_low; > > +    } > >     z.high = ( ( (uint16_t) a.sign )<<15 ) | 0x7FFF; > >     return z; > >  } > > I think the condition here should be "if (a.high >> 1)" -- otherwise we > might construct an infinity instead (explicit bit 1 but all fraction bits 0). > Also we are keeping the sign of the input even if we return the default > NaN. It might be better to start with > uint64_t mantissa = a.high >> 1; > and then roll the 'mantissa == 0' check into the default_nan_mode if(). > Correct, good catch. Will fix that in v2. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net