qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features sup


From: Leon Alrae
Subject: Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support
Date: Tue, 10 Feb 2015 10:44:38 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 09/02/2015 20:55, Maciej W. Rozycki wrote:
>>> +uint32_t helper_float_chs_s(CPUMIPSState *env, uint32_t fst0)
>>> +{
>>> +    uint32_t fst1;
>>> +
>>> +    fst1 = float32_sub(0, fst0, &env->active_fpu.fp_status);
>>> +    update_fcr31(env, GETPC());
>>> +    return fst1;
>>> +}
>>
>> I think there is one case where helper_float_chs_{d,s,ps} are not
>> correct -- when we have zero. In this case in subFloat32Sigs() we call:
>>
>> return packFloat32(status->float_rounding_mode == float_round_down, 0, 0);
>>
>> and the packFloat32() definition:
>>
>> static inline float32 packFloat32(flag zSign, int_fast16_t zExp,
>> uint32_t zSig)
>> {
>>
>>     return make_float32(
>>           ( ( (uint32_t) zSign )<<31 ) + ( ( (uint32_t) zExp )<<23 ) +
>> zSig);
>>
>> }
>>
>> Which means that the sign may not get changed, whereas I believe NEG.fmt
>> is supposed to reverse the sign bit of positive/negative zero regardless
>> of rounding mode.
> 
>  Good catch, I missed this corner case, thanks!  Another corner case is 
> then helper_float_abs_{d,s,ps} with -0 as input and `float_round_down' 
> being the current rounding mode.
> 
>  These cases could be addressed by either replacing subtraction from 0.0 
> with multiplication by -1.0, or by tweaking the rounding mode as needed 
> temporarily.  Given that the computational cost of multiplication is 
> uncertain and likely higher or at best the same as the cost of addition or 
> subtraction, I'd be leaning towards the latter solution.

My first thought was to treat zero in NEG.fmt as a special case and use
float32_chs() for it. But tweaking the rounding mode temporarily
probably is better as we will get consistent behaviour for zero as well
as input denormals which are squashed in float32_sub() when
flush_inputs_to_zero flag is set (actually I'm not sure if legacy fp
instructions should flush input denormals, but according to the spec
this is implementation dependent so I won't worry about this).

Leon



reply via email to

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