From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] mips: add single-instruction math functions
Date: Fri, 13 Sep 2019 16:01:41 -0400 [thread overview]
Message-ID: <20190913200141.GL9017@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAA2zVHp1w_cb_2S1-9ggLvw1EAxfbZ1bPWccw8B2SoMzt0iW5g@mail.gmail.com>
On Fri, Sep 13, 2019 at 03:12:11PM -0400, James Y Knight wrote:
> I've no idea about the issues with MIPS' instruction set, but yes, to be
> correct, abs does need to affect only the sign bit, leaving everything else
> the same.
>
> It's specified as such in IEEE 754-2008: 5.5.1 Sign bit operations --
> "Implementations shall provide the following homogeneous
> quiet-computational sign bit operations for all supported arithmetic
> formats; they only affect the sign bit. The operations treat floating-point
> numbers and NaNs alike, and signal no exception. These operations may
> propagate non-canonical encodings."
> ....
> "abs(x) copies a floating-point operand x to a destination in the same
> format, setting the sign bit to 0 (positive)."
>
> (That section also defines the copy, negate, and copySign operations)
OK, the text I was missing was:
"The fabs functions in <math.h> provide the abs function recommended
in the Appendix to IEC 60559."
from F.3 ¶1.
Rich
> On Fri, Sep 13, 2019 at 2:57 PM Rich Felker <dalias@libc.org> wrote:
>
> > On Fri, Sep 13, 2019 at 02:31:23PM -0400, Rich Felker wrote:
> > > On Wed, Sep 11, 2019 at 01:05:04PM +0300, info@mobile-stream.com wrote:
> > > >
> > > > non-commit text:
> > > > gcc puts annoying nop into the delay slot for these functions, e.g.:
> > > > abs.d $f0,$f12
> > > > jr $ra
> > > > nop
> > > > is there any way to get rid of this without using pure .S?
> > > >
> > > >
> > > >
> > > > SQRT.fmt exists on MIPS II+ (float), MIPS III+ (double).
> > > >
> > > > ABS.fmt exists on MIPS I+ but only cores with ABS2008 flag in FCSR
> > > > implement the required behaviour.
> > > > ---
> > > > src/math/mips/fabs.c | 16 ++++++++++++++++
> > > > src/math/mips/fabsf.c | 16 ++++++++++++++++
> > > > src/math/mips/sqrt.c | 16 ++++++++++++++++
> > > > src/math/mips/sqrtf.c | 16 ++++++++++++++++
> > > > 4 files changed, 64 insertions(+)
> > > > create mode 100644 src/math/mips/fabs.c
> > > > create mode 100644 src/math/mips/fabsf.c
> > > > create mode 100644 src/math/mips/sqrt.c
> > > > create mode 100644 src/math/mips/sqrtf.c
> > > >
> > > > diff --git a/src/math/mips/fabs.c b/src/math/mips/fabs.c
> > > > new file mode 100644
> > > > index 00000000..0a5aa3b1
> > > > --- /dev/null
> > > > +++ b/src/math/mips/fabs.c
> > > > @@ -0,0 +1,16 @@
> > > > +#if !defined(__mips_soft_float) && defined(__mips_abs2008)
> > >
> > > Why is this dependent on __mips_abs2008?
> >
> > OK, I see. The macro isn't well-documented, but it corresponds to the
> > gcc -mabs=2008 option indicating an ISA variant that treats the
> > abs.[sd] instruction as bitwise rather than arithmetic. I'm somewhat
> > unclear on whether we should do anything like this; it's one of the
> > places where MIPS blurred the distinction between ISA levels and
> > incompatible ABIs, and seems to be able to produce code that would
> > silently run on the wrong type of cpu and produce the wrong result (or
> > maybe this is a runtime-switchable cpu mode?)
> >
> > I'm also unclear though whether fabs() actually needs to behave as
> > bitwise. Neither C nor Annex F nor POSIX seems to specify its behavior
> > for NANs except that a NAN is returned. Am I missing something? If
> > not, it seems the 'legacy' abs.[sd] instructions would also be fine
> > for implementing this, and then no conditional is needed.
> >
> > Rich
> >
next prev parent reply other threads:[~2019-09-13 20:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 10:05 info
2019-09-11 11:46 ` Rich Felker
2019-09-12 17:57 ` Rich Felker
2019-09-13 11:46 ` info
2019-09-13 18:31 ` Rich Felker
2019-09-13 18:56 ` Rich Felker
2019-09-13 19:12 ` James Y Knight
2019-09-13 20:01 ` Rich Felker [this message]
2019-09-13 20:23 ` Rich Felker
2019-09-18 13:07 ` info
2019-09-18 13:49 ` Rich Felker
2019-09-18 17:18 ` info
2019-09-18 20:04 ` Rich Felker
2019-09-19 12:54 ` info
2019-09-19 13:14 ` Rich Felker
2019-09-19 13:25 ` Rich Felker
2019-09-19 18:26 ` info
2019-09-19 19:10 ` Rich Felker
2019-10-14 14:18 ` Rich Felker
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=20190913200141.GL9017@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).