Re: Revisiting More Complete long double Support

I've dug in a bit and tried to bring in one function. Found
a few things that are going to shape the solution:

(1)  Newlib and FreeBSD do not agree on filenames. truncl.c
      gets replaced by s_truncl.c
     (a) Great work on the new build system. :)

(2) FreeBSD long double methods rely on _fpmath.h to define
     the long double format. It doesn't have to be 128 bits for the
     code to work. But only a handful of architectures have this file:

      aarch64 amd64 arm i386 mips powerpc powerpc64 riscv sparc64

      This file would go in libc/machine/... I think based on the FreeBSD
      source layout.

(3) I think my suggestion to have the default implementation and
      then this implementation in parallel and then select the appropriate
      one at configure time. For the architectures with _fpmath.h, the
      new FreeBSD implementation can be used. For others, architectures
      the old implementation could be used.

Unfortunately, I started working with sparc which does not have an
_fpmath.h. I will try one of the architectures with _fpmath.h tomorrow.

But it looks like a wholesale update isn't going to work out.

I want to get one long double method building for an architecture
with and one without _fpmath.h with whatever structure we decide
on before I start repeating that.

Thoughts?

--joel

--joel

On Thu, Aug 18, 2022 at 2:31 PM Joel Sherrill <[email protected]> wrote:

>
>
> On Thu, Aug 18, 2022 at 2:16 PM Corinna Vinschen <[email protected]>
> wrote:
>
>> 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...
>>
>
> Yeah. I have been tracking newlib/RTEMS against various FACE
> Technical Standard POSIX profiles. fenv was also part of the missing
> functionality. The long double math is the bulk of what's left to address.
>
>>
>> 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.
>>
>
> Agreed. If the FreeBSD code works when _LDBL_EQ_DBL and when it isn't.
> I honestly can't tell by looking at the FreeBSD e_acosl.c,
>
> I'll put it in my todo list to experiment to see what happens just
> replacing it.
>
> If someone sees an obvious problem, please speak up.
>
> If it doesn't work, then falling back to the current implementations may
> be
> needed. But we can try to avoid it.
>
>>
>> > > > (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
>>
>>