From: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 1/5] target-tricore: Added FTOUZ instruction
Date: Wed, 9 Nov 2016 16:46:40 +0100 [thread overview]
Message-ID: <bad0d2d6-884d-08bd-5f57-6e0a88323ad2@mail.uni-paderborn.de> (raw)
In-Reply-To: <bc0ac028-75e6-e676-4821-541b0a6dcf0e@twiddle.net>
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
next prev parent reply other threads:[~2016-11-09 15:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 14:44 [Qemu-devel] [PATCH v2 0/5] Bastian Koppelmann
2016-11-07 14:44 ` [Qemu-devel] [PATCH v2 1/5] target-tricore: Added FTOUZ instruction Bastian Koppelmann
2016-11-08 11:36 ` Richard Henderson
2016-11-08 13:37 ` Bastian Koppelmann
2016-11-08 15:06 ` Richard Henderson
2016-11-08 15:12 ` Bastian Koppelmann
2016-11-08 15:25 ` Richard Henderson
2016-11-09 15:46 ` Bastian Koppelmann [this message]
2016-11-07 14:44 ` [Qemu-devel] [PATCH v2 2/5] target-tricore: Added MADD.F and MSUB.F instructions Bastian Koppelmann
2016-11-08 11:42 ` Richard Henderson
2016-11-08 15:08 ` Bastian Koppelmann
2016-11-08 15:10 ` Richard Henderson
2016-11-07 14:44 ` [Qemu-devel] [PATCH v2 3/5] target-tricore: Added new MOV instruction variant Bastian Koppelmann
2016-11-08 11:44 ` Richard Henderson
2016-11-07 14:44 ` [Qemu-devel] [PATCH v2 4/5] target-tricore: Added new JNE " Bastian Koppelmann
2016-11-07 14:44 ` [Qemu-devel] [PATCH v2 5/5] target-tricore: Add updfl instruction Bastian Koppelmann
2016-11-08 11:49 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bad0d2d6-884d-08bd-5f57-6e0a88323ad2@mail.uni-paderborn.de \
--to=kbastian@mail.uni-paderborn.de \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).