On 11/08/2016 04:25 PM, Richard Henderson wrote:
> On 11/08/2016 04:12 PM, Bastian Koppelmann wrote:
>> On 11/08/2016 04:06 PM, Richard Henderson wrote:
>>> On 11/08/2016 02:37 PM, Bastian Koppelmann wrote:
>>>> Consider 0x836d4e86 as an input which is clearly negative, however
>>>> float_flag_invalid is not set. The hardware on the other hand does set
>>>> it.
>>>
>>> Hmm. This is -0x1.da9d0cp-121. Softfloat claims that we should round
>>> to zero first, and only if the result is still < 0, raise invalid.
>>> Which does sound plausible as a common behaviour.
>>
>> TriCore does it the other way round.
>>
>>>
>>> Does your hardware raise invalid for true -0.0, i.e. 0x80000000?
>>
>> No, -0.0 does not raise invalid.
>
> Then I suppose the check should look like
>
> flags = f_get_excp_flags(env);
> if (flags & float_flag_invalid) {
> flags &= ~float_flag_inexact;
> } else if (float32_lt_quiet(f_arg, 0, &env->status)) {
> flags = float_flag_invalid;
> }
> if (flags) {
> f_update_psw_flags(env, flags);
> }
>
> Note that the 0.0 that you use is truncated to 0 by C for the uint32_t
> argument.
Not quite -- it does not catch that an input NaN results in 0 as opposed
to -1 returned by softfloat.
But otherwise thanks for the review. This resulted in much nicer code.
Cheers,
Bastian
