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

[Peter Maydell <peter.maydell@linaro.org>]

On 2 January 2011 15:05, Aurelien Jarno <aurelien@aurel32.net> 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.

>> Isn't it clearing the FP exception flags for each instruction when
>> they ought to be cumulative?

> It only clears the softfloat ones, the real ones are kept in CPU
> register fcr31, which is updated by update_fcr31(). This allows to
> correctly emulate fcr31, as it contains a part that cumulates IEEE754
> flags and can be reset by software, and a part that cumulates exception
> flags, which triggers exceptions if enabled, and which can be reset
> independently.

Ah yes, I hadn't spotted that we were calling UPDATE_FP_FLAGS
rather than SET_FP_FLAGS in update_fcr31(). Sorry for the false
alarm.

-- PMM