From: Peter Maydell <peter.maydell@linaro.org>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 4/5] softfloat: add float{32, 64, x80, 128}_unordered() functions
Date: Sun, 10 Apr 2011 20:59:04 +0100 [thread overview]
Message-ID: <BANLkTin4mxR0F1FUawnnEh21-KoVrC6yNA@mail.gmail.com> (raw)
In-Reply-To: <1302462807-8795-4-git-send-email-aurelien@aurel32.net>
On 10 April 2011 20:13, Aurelien Jarno <aurelien@aurel32.net> wrote:
> Add float{32,64,x80,128}_unordered() functions to softfloat, matching
> the softfloat-native ones. This allow target-i386/ops_sse.h to be
> compiled with softfloat.
I guess you could have made the x86 target use float*_compare()
instead, but I agree that it makes sense to have the unordered()
comparison to match the other specific-comparison ops.
> /*----------------------------------------------------------------------------
> +| Returns 1 if the single-precision floating-point values `a' and `b' cannot
> +| be compared, and 0 otherwise. The comparison is performed according to the
> +| IEC/IEEE Standard for Binary Floating-Point Arithmetic.
> +*----------------------------------------------------------------------------*/
> +
> +int float32_unordered( float32 a, float32 b STATUS_PARAM )
> +{
> + a = float32_squash_input_denormal(a STATUS_VAR);
> + b = float32_squash_input_denormal(b STATUS_VAR);
> +
> + if ( ( ( extractFloat32Exp( a ) == 0xFF ) && extractFloat32Frac( a ) )
> + || ( ( extractFloat32Exp( b ) == 0xFF ) && extractFloat32Frac( b ) )
> + ) {
> + if ( float32_is_signaling_nan( a ) || float32_is_signaling_nan( b ) ) {
> + float_raise( float_flag_invalid STATUS_VAR);
> + }
> + return 1;
> + }
> +
> + return 0;
> +}
So the NaN signalling semantics here are that we raise Invalid
for an SNaN but not for a QNaN. That's correct for the x86 op
we're implementing, but the float*_lt, _le and _compare functions
use the _quiet suffix for these semantics (with plain float*_lt
etc being "raise Invalid for both QNaN and SNaN"). So I think
these functions should be float*_unordered_quiet().
Annoyingly for eq the two versions use a different convention,
so we have float*_eq [raise Invalid only if SNaN] and
float*_eq_signaling [for any NaN] -- ideally that inconsistency
should be fixed...
> +int float64_unordered( float64 a, float64 b STATUS_PARAM )
> +{
> + a = float64_squash_input_denormal(a STATUS_VAR);
> + b = float64_squash_input_denormal(b STATUS_VAR);
> +
> + if ( ( ( extractFloat64Exp( a ) == 0x7FF ) && extractFloat64Frac( a ) )
> + || ( ( extractFloat64Exp( b ) == 0x7FF ) && extractFloat64Frac( b ) )
> + ) {
> + if ( float64_is_signaling_nan( a ) || float64_is_signaling_nan( b ) ) {
> + float_raise( float_flag_invalid STATUS_VAR);
> + }
> + return 0;
> + }
> + return 1;
> +}
You've got the sense the wrong way round on this one, I think.
I note that target-mips has a private float32_is_unordered()
and float64_is_unordered() which could probably be cleaned
up to use these instead. You'd need to implement both the
float*_unordered() and float*_unordered_quiet() versions.
-- PMM
next prev parent reply other threads:[~2011-04-10 19:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-10 19:13 [Qemu-devel] [PATCH 1/5] cpu-all.h: define CPU_LDoubleU Aurelien Jarno
2011-04-10 19:13 ` [Qemu-devel] [PATCH 2/5] target-i386: use CPU_LDoubleU instead of a private union Aurelien Jarno
2011-04-10 19:13 ` [Qemu-devel] [PATCH 3/5] target-i386: fix cpu-exec.o build with softfloat Aurelien Jarno
2011-04-10 20:18 ` [Qemu-devel] " Peter Maydell
2011-04-10 19:13 ` [Qemu-devel] [PATCH 4/5] softfloat: add float{32, 64, x80, 128}_unordered() functions Aurelien Jarno
2011-04-10 19:59 ` Peter Maydell [this message]
2011-04-10 21:00 ` [Qemu-devel] " Aurelien Jarno
2011-04-10 19:13 ` [Qemu-devel] [PATCH 5/5] target-i386: add floatx_{add, mul, sub} and use them Aurelien Jarno
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=BANLkTin4mxR0F1FUawnnEh21-KoVrC6yNA@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=aurelien@aurel32.net \
--cc=qemu-devel@nongnu.org \
/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).