From: Corinna Vinschen <vinschen@redhat.com>
To: Joel Sherrill <joel@rtems.org>, newlib@sourceware.org
Subject: Re: Revisiting More Complete long double Support
Date: Thu, 18 Aug 2022 21:16:37 +0200 [thread overview]
Message-ID: <Yv6QFWBdvTCMyaE0@calimero.vinschen.de> (raw)
In-Reply-To: <CAF9ehCWvEL4bvKUVe+W=U=CNXxK-bAid4b6c8iNq7TB+L6Fm4g@mail.gmail.com>
On Aug 18 09:49, Joel Sherrill wrote:
> On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen wrote:
> > On Aug 17 17:06, Joel Sherrill wrote:
> > > [...]
> > > ifdef _LDBL_EQ_DBL
> > > long double
> > > acosl (long double x)
> > > {
> > > return acos(x);
> > > }
> > > #else
> > > #include "acosl_freebsd.c"
> > > #endif
> > >
> > > which would definitely avoid edits to the FreeBSD source.
> >
> > Question is, do we really still need this?
> >
> > These #ifdef have been added just as a cheap workaround for small
> > targets, because nobody provided the actual long double implementations,
> > yet. If we merge the actual long double implementations from FreeBSD,
> > there's no need for this anymore and we can probably drop the
> > _LDBL_EQ_DBL flag entirely.
>
> I think that's hopeful thinking although I like the idea of importing the
> FreeBSD code. I have attached a slightly updated version of the script
> I used to probe which targets were _LDBL_EQ_DBL. Two yes'es means
> that _LDBL_EQ_DBL implementation is used. Two no's means that
> it needs a real long double implementation -- if my script and probe program
> are correct.
>
> has_long_double]$ sh j
> TARGET in lib ldbl=dbl
> ================= ====== ========
> aarch64-rtems6 no no
> arm-rtems6 yes yes
> bfin-rtems6 yes yes
> i386-rtems6 no no
> lm32-rtems6 yes yes
> m68k-rtems6 no no
> microblaze-rtems6 yes yes
> mips-rtems6 yes yes
> moxie-rtems6 yes yes
> nios2-rtems6 yes yes
> or1k-rtems6 yes yes
> powerpc-rtems6 yes yes
> riscv-rtems6 no no
> sh-rtems6 yes yes
> sparc64-rtems6 no no
> sparc-rtems6 yes yes
> v850-rtems6 yes yes
> x86_64-rtems6 no no
>
> Hopefully that aligns ok on your side. Most of the targets seem to be able
> to legitimately use the current _LDBL_EQ_DBL implementations.
They might be able to use it, but if so, they are only able to do so
since 2009. It was really just a cheap trick to allow calling long
double functions on targets which don't require a real long double lib.
As you may remember, it's not the first time we talk about long double
functions...
However, if we have a *real*, generic implementation of all long double
functions, there's just no need to keep up with the _LDBL_EQ_DBL hackery.
> > > (2) More i386 assembly versions
> > >
> > > Then there appears to be some long double methods for the i386/87 here
> > > which newlib doesn't currently have:
> > >
> > > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/i387
> > >
> > > Thoughts on adding this long double code from FreeBSD?
> >
> > ...and merge the occasional CPU-specific assembler code from
> > FreeBSD's lib/msun/<cpu> into our libm/machine/<cpu> dir, that
> > should work nicely.
> >
>
> :)
>
> I think you've said in the past that Cygwin has these but the
> calling conventions are different. Is that something that has to
> be taken into account in newlib?
No worries. It wouldn't matter for i386, but we dropped 32 bit support
in master anyway. For x86_64, Cygwin uses the Windows AMD64 calling
convention, so we can't use the assembler functions using the standard
calling convention there.
As a side note, I added x86_64 assembler memcpy/memset functions from
FreeBSD to Cygwin at one point. The code is untouched, I just added
wrapper code which reshuffles the arg registers according to the
different calling conventions.
That could help using the FreeBSD x86_64 long double functions for
Cygwin, too, using wrapper macros or something like that. However, the
Mingw64 long double functions work nicely for a couple of years, so
there's no reason to force this. We're sticking to the Mingw64
functions in Cygwin for the time being.
Corinna
next prev parent reply other threads:[~2022-08-18 19:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 22:06 Joel Sherrill
2022-08-18 7:57 ` Corinna Vinschen
2022-08-18 14:49 ` Joel Sherrill
2022-08-18 19:16 ` Corinna Vinschen [this message]
2022-08-18 19:31 ` Joel Sherrill
2022-08-18 22:16 ` Joel Sherrill
2022-08-19 9:19 ` Corinna Vinschen
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=Yv6QFWBdvTCMyaE0@calimero.vinschen.de \
--to=vinschen@redhat.com \
--cc=joel@rtems.org \
--cc=newlib@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).