qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules
Date: Mon, 3 Jan 2011 00:00:05 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jan 02, 2011 at 03:35:30PM +0000, Peter Maydell wrote:
> On 2 January 2011 15:05, Aurelien Jarno <address@hidden> wrote:
> > On Sun, Jan 02, 2011 at 02:04:11PM +0000, Peter Maydell wrote:
> >> Could we have a target-specific "silence this SNaN" function?
> >
> > You mean a target-specific version of floatXX_maybe_silence_nan()?
> 
> Actually what I had in mind was a target-specific floatXX_silence_snan()
> which would be called from the propagateFloatXX_NaN()
> and floatXX_maybe_silence_nan() functions. But now you mention
> it, just allowing the target to override floatXX_maybe_silence_nan()
> (and calling it in propagateFloatXX_NaN()) looks like the better thing.
> 
> > At least having a default version (for !SNAN_BIT_IS_ONE) and a version
> > for MIPS, HPPA (which is btw not emulated), etc.
> 
> Yes. (Incidentally, HPPA says the rule for "silence this NaN" is:
>  * set the first bit of the significand to 0
>  * set the second bit of the significand to 1 (implementations can do
> this (a) always or (b) only if all the other bits of the significand are 0)
> Of course we don't need to actually implement this since
> as you say we don't have an HPPA target, but it does suggest
> that "silencing rules are target-specific" is the right approach.)
> 
> >> Then the top level functions could use those rather than doing
> >> their own bit-flipping, and I think that would do the right thing
> >> for MIPS (you'd implement silence-NaN as "return the default
> >> QNaN", and you implement pickNaN() to return the SNaN.)
> >
> > It seems, it would be the good way to do it. I am going to do a quick
> > hack to see if this solution can work and if it is the case (it seems
> > to be), apply your patch.
> 
> Cool.
> 

I confirm this solution works. I have applied your patches, I'll send a
patch series to implement correct propagation on MIPS later this week.

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



reply via email to

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