All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH 4/5] softfloat: add float{32, 64, x80, 128}_unordered() functions
Date: Sun, 10 Apr 2011 23:00:04 +0200	[thread overview]
Message-ID: <20110410210004.GN28617@hall.aurel32.net> (raw)
In-Reply-To: <BANLkTin4mxR0F1FUawnnEh21-KoVrC6yNA@mail.gmail.com>

On Sun, Apr 10, 2011 at 08:59:04PM +0100, Peter Maydell wrote:
> 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.

Given it's used in the same macro which also handle float*_le, _ge and
so on, it was easier that way. Also float*_compare() is probably a bit
slower as it does a bit more stuff.

> >  /*----------------------------------------------------------------------------
> > +| 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().

Ok, will change that.

> 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...

I'll try to send a patch for that in my next version of the series.

> > +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.

Yup, good catch.

> 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.
> 

I missed that when running grep. I'll also add that in my next version
of the series (so that will be x86 + mips at the end).

Thanks for the review!

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

  reply	other threads:[~2011-04-10 21:00 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   ` [Qemu-devel] " Peter Maydell
2011-04-10 21:00     ` Aurelien Jarno [this message]
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=20110410210004.GN28617@hall.aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=peter.maydell@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.