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