[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