[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
- Re: [Qemu-devel] [PATCH v2 3/5] target-tricore: Added new MOV instruction variant, (continued)
[Qemu-devel] [PATCH v2 2/5] target-tricore: Added MADD.F and MSUB.F instructions, Bastian Koppelmann, 2016/11/07