qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/5] target-tricore: Added FTOUZ instruction


From: Bastian Koppelmann
Subject: Re: [Qemu-devel] [PATCH v2 1/5] target-tricore: Added FTOUZ instruction
Date: Wed, 9 Nov 2016 16:46:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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




reply via email to

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