public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* Revisiting More Complete long double Support
@ 2022-08-17 22:06 Joel Sherrill
  2022-08-18  7:57 ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2022-08-17 22:06 UTC (permalink / raw)
  To: Newlib

Hi

I'm looking at newlib long double support again when sizeof(long double) !=
sizeof(double).

(1) Merged FreeBSD C code for long double math

FreeBSD has C code for long double math routines as default implementation:

https://github.com/freebsd/freebsd-src/tree/main/lib/msun/src

I **THINK** those will work if LDBL != DBL so that code might need the
ifdef for LDBL_EQ_DBL to pick the current newlib common implementation of
the method which just calls the normal version of the method.  I code even
add the files as XXX_freebsd.c and only add

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.

(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?

Thanks.

--joel

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-17 22:06 Revisiting More Complete long double Support Joel Sherrill
@ 2022-08-18  7:57 ` Corinna Vinschen
  2022-08-18 14:49   ` Joel Sherrill
  0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2022-08-18  7:57 UTC (permalink / raw)
  To: newlib

On Aug 17 17:06, Joel Sherrill wrote:
> Hi
> 
> I'm looking at newlib long double support again when sizeof(long double) !=
> sizeof(double).
> 
> (1) Merged FreeBSD C code for long double math
> 
> FreeBSD has C code for long double math routines as default implementation:
> 
> https://github.com/freebsd/freebsd-src/tree/main/lib/msun/src
> 
> I **THINK** those will work if LDBL != DBL so that code might need the
> ifdef for LDBL_EQ_DBL to pick the current newlib common implementation of
> the method which just calls the normal version of the method.  I code even
> add the files as XXX_freebsd.c and only add
> 
> 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.

If we just merge the long double code from FreeBSD's lib/msun/src
into our libm/common dir...

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


Corinna


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-18  7:57 ` Corinna Vinschen
@ 2022-08-18 14:49   ` Joel Sherrill
  2022-08-18 19:16     ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2022-08-18 14:49 UTC (permalink / raw)
  To: Newlib

[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]

On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 17 17:06, Joel Sherrill wrote:
> > Hi
> >
> > I'm looking at newlib long double support again when sizeof(long double)
> !=
> > sizeof(double).
> >
> > (1) Merged FreeBSD C code for long double math
> >
> > FreeBSD has C code for long double math routines as default
> implementation:
> >
> > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/src
> >
> > I **THINK** those will work if LDBL != DBL so that code might need the
> > ifdef for LDBL_EQ_DBL to pick the current newlib common implementation of
> > the method which just calls the normal version of the method.  I code
> even
> > add the files as XXX_freebsd.c and only add
> >
> > 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.

What about two directories of long double implementations. One
is for _LDBL_EQ_DBL and the other is the FreeBSD code. I think
libm/Makefile.inc already has an example of picking one of two
directories based on an automake flag. Adding one for to reflect
_LDBL_EQ_DBL and picking either one of the two long double
math implementation directories should work.

Names are always an issue. I have no ideas for good names for
the directories. Something somewhat horrible like
common/ldbl_eq_double and common/ldbl are the best I have.


> If we just merge the long double code from FreeBSD's lib/msun/src
> into our libm/common dir...
>

Maybe a subdirectory or parallel directory so we can keep the
_LDBL_EQ_DBL where it is needed.

>
> > (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?

--joel

>
>
> Corinna
>
>

[-- Attachment #2: has_long_double.tar.xz --]
[-- Type: application/octet-stream, Size: 1548 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-18 14:49   ` Joel Sherrill
@ 2022-08-18 19:16     ` Corinna Vinschen
  2022-08-18 19:31       ` Joel Sherrill
  0 siblings, 1 reply; 7+ messages in thread
From: Corinna Vinschen @ 2022-08-18 19:16 UTC (permalink / raw)
  To: Joel Sherrill, newlib

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-18 19:16     ` Corinna Vinschen
@ 2022-08-18 19:31       ` Joel Sherrill
  2022-08-18 22:16         ` Joel Sherrill
  0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2022-08-18 19:31 UTC (permalink / raw)
  To: Newlib, Joel Sherrill

On Thu, Aug 18, 2022 at 2:16 PM Corinna Vinschen <vinschen@redhat.com>
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
>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-18 19:31       ` Joel Sherrill
@ 2022-08-18 22:16         ` Joel Sherrill
  2022-08-19  9:19           ` Corinna Vinschen
  0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2022-08-18 22:16 UTC (permalink / raw)
  To: Newlib, Joel Sherrill

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 <joel@rtems.org> wrote:

>
>
> On Thu, Aug 18, 2022 at 2:16 PM Corinna Vinschen <vinschen@redhat.com>
> 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
>>
>>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Revisiting More Complete long double Support
  2022-08-18 22:16         ` Joel Sherrill
@ 2022-08-19  9:19           ` Corinna Vinschen
  0 siblings, 0 replies; 7+ messages in thread
From: Corinna Vinschen @ 2022-08-19  9:19 UTC (permalink / raw)
  To: Joel Sherrill; +Cc: Newlib

On Aug 18 17:16, Joel Sherrill wrote:
> 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. :)

We can easily change this to the FreeBSD naming convention.  We're
using it mostly anyway.

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

_fpmath.h defines one union and 5 macros.  It's very basic.

We have already multiple files defining structs and unions based on the
value of LDBL_MANT_DIG, libc/include/ieeefp.h,
libc/include/machine/ieee.h, and libc/stdio/vfieeefp.h.

The most useful way of action would probably be to define a common
_fpmath.h with all the required structs, unions and macros and use
that throughout, i. e., we include it from the above files.

And ideally we only have one *ieee*.h file, not three, in future...

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

Dunno about others, but I'd rather not see two parallel implementations
of math in newlib.  It might be a bit more work to port the code, but
it's certainly not unfeasible.


Corinna


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-08-19  9:19 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-17 22:06 Revisiting More Complete long double Support Joel Sherrill
2022-08-18  7:57 ` Corinna Vinschen
2022-08-18 14:49   ` Joel Sherrill
2022-08-18 19:16     ` Corinna Vinschen
2022-08-18 19:31       ` Joel Sherrill
2022-08-18 22:16         ` Joel Sherrill
2022-08-19  9:19           ` Corinna Vinschen

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