qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Softfloat: Add support to softfloat to return f


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH] Softfloat: Add support to softfloat to return floatxx_default_nan when the corresponding target status flag is set.
Date: Fri, 4 Feb 2011 20:47:02 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Feb 04, 2011 at 02:44:48PM +0000, Peter Maydell wrote:
> On 4 February 2011 14:01, Christophe Lyon <address@hidden> wrote:
> > Some CPUs have a status flag imposing to return floatxx_default_nan
> > whatever the input value, when converting from one FP format to
> > another. Implement this, using the already existing default_nan_mode
> > status flag, only for ARM at the moment, though other architectures
> > may have the same feature. This patch only modifies the
> > commonNaNToFloat32 and commonNaNToFloat64 conversion functions, as ARM
> > only uses these.
> 
> > -static float32 commonNaNToFloat32( commonNaNT a )
> > +static float32 commonNaNToFloat32( commonNaNT a STATUS_PARAM )
> >  {
> >     bits32 mantissa = a.high>>41;
> > +
> > +#if defined(TARGET_ARM)
> > +    if ( STATUS(default_nan_mode) ) {
> > +        return float32_default_nan;
> > +    }
> > +#endif
> 
> The target-specific #ifdef is pretty ugly.
> Fortunately the only architecture except ARM that sets
> default_nan_mode is sh4, so all we have to do is find out
> what it does with its float-to-float conversions. It looks
> to me from
> http://documentation.renesas.com/eng/products/mpumcu/rej09b0318_sh_4sm.pdf
> that it also returns the default NaN for converting a NaN
> from one float format to another. So you can just drop the
> #ifdef.

I confirm that the same bug is present on SH4 (tested on real hardware),
so the same fix is needed there. Thanks for catching that. Can you
please resend your patch without the #ifdef?

> (cc'ing Aurelien to check since he's the SH4 maintainer.)
> 
> I also think the change is simple enough that we ought to do
> it consistently for the floatx80 and float128 functions even if
> neither ARM nor sh4 use them.
> 

Agreed.


-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]