qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/6] softfloat: remove HPPA specific code


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 1/6] softfloat: remove HPPA specific code
Date: Thu, 6 Jan 2011 22:31:22 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Jan 06, 2011 at 09:19:13PM +0000, Peter Maydell wrote:
> On 6 January 2011 18:48, Aurelien Jarno <address@hidden> wrote:
> > On Thu, Jan 06, 2011 at 03:34:38PM +0000, Peter Maydell wrote:
> >> In helper_fnmadd() and helper_fnmsub():
> >>         if (likely(!float64_is_quiet_nan(farg1.d)))
> >>             farg1.d = float64_chs(farg1.d);
> >>
> >> is I think OK but somebody else might like to check.
> >
> > After reading the manual again, it seems float64_is_nan() should be used
> > here. The idea is that fnmadd returns the negated value of fmadd, and
> > that NaN should be propagated as fnmadd was a single instruction. In
> > QEMU chs changes the sign bit even if the value is NaN. Quoting the
> > manual:
> >
> > | This instruction produces the same result as would be obtained by
> > | using the Floating Multiply-Add instruction and then negating the
> > | result, with the following exceptions.
> > | * QNaNs propagate with no effect on their "sign" bit.
> > | * QNaNs that are generated as the result of a disabled Invalid
> > |   Operation Exception have a "sign" bit of 0.
> > | * SNaNs that are converted to QNaNs as the result of a disabled
> > | Invalid Operation Exception retain the "sign”"bit of the SNaN.
> 
> Yes, I read that text, but I kind of convinced myself that at
> that point in the code it wasn't possible to get a signalling NaN
> (since they've been handled earlier). Still, the _any_nan() check
> is probably clearer code.
> 

For the long term I plan to add softfloat to have more granularity in
the invalid exception flags so that we can implement most PowerPC FP
without checking the operand first, and just looking at the softfloat 
exception flags. This will use this code path, so that's better to fix
it as it is spotted.

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



reply via email to

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