Re: [Qemu-devel] [PATCH v3] Softfloat: Add support to softfloat to return floatxx_default_nan when, the corresponding target status flag is set.

[Aurelien Jarno <aurelien@aurel32.net>]

Hi,

On Tue, Feb 08, 2011 at 08:06:57PM +0000, Peter Maydell wrote:
> On 8 February 2011 18:53, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 8 February 2011 17:51, Christophe Lyon <christophe.lyon@st.com> wrote:
> >> - this means implementing float16ToCommonNaN, thus float16_is_signaling_nan()
> >
> > ...like that, yes.
> 
> I have a slightly-tested implementation of these functions on my
> hard disk now; I'll try to finish testing them tomorrow (my testing
> is still falling over on some inputs to VCVTT/VCVTB).
> 
> (cc: Aurelien for the softfloat style questions:)
> 
> I think we should go ahead and define a float16 type.

I fully agree with that. I have seen you have already sent patches about
that, will look at them later.

> Also, at the moment the commonNaNToFloatX(floatYToCommonNaN())
> idiom doesn't do anything to avoid signaling NaNs showing up in
> the output. On ARM this got fixed by having the helper.c wrappers
> call float*_maybe_silence_nan() but maybe we should do it
> in the generic softfloat code?
> 
> ie instead of:
> 
>     if ( mantissa )
>         return make_float32(
>             ( ( (bits32) a.sign )<<31 ) | 0x7F800000 | ( a.high>>41 ) );
>     else
>         return float32_default_nan;
> 
> do:
>    float32 r = make_float32(
>             ( ( (bits32) a.sign )<<31 ) | 0x7F800000 | ( a.high>>41 ) );

On an unrelated note, if we changes in this function, it might be a good
idea to use mantissa instead of a.high>>41. It's the same, but probably 
easier to read.

>    if (!mantissa) {
>       /* target specific, !SNAN_BIT_IS_ONE targets probably
>        * just set the QNAN bit (true for ARM, SPARC)
>        * others likely return the default NaN ?
>        */
>    } else {
>       return float32_maybe_silence_nan(r);
>    }
> 
> I'm pretty sure the existing code is wrong for SPARC, for instance,
> which is supposed to return a float32 qNaN with just the QNAN bit set
> if it is presented with a float64 signalling NaN all of whose non-zero
> mantissa bits are at the bottom end and don't make it into the float32.
> (ARM dodges a bullet here because as it happens our float32
> default_nan has only the QNAN bit set, but SPARC's has all the
> mantissa bits set.)
> 
> Opinions?
> 

It makes sense. I will play a bit with a real MIPS machine to see how it
behaves and come back with my results.

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