i386 long double math methods

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

i386 long double math methods

Joel Sherrill
Hi

i386-rtems tools do not include long double math routines but Cygwin
does and there is a comment in math.h indicating they have code
elsewhere for these. I went looking for implementations to include in
newlib's libm and it looks like the MIT licensed MUSL has them.

http://git.musl-libc.org/cgit/musl/tree/src/math/i386

Are these OK to use to fill in the long double gaps?

--joel
Reply | Threaded
Open this post in threaded view
|

Re: i386 long double math methods

Brian Inglis
On 2019-09-25 16:06, Joel Sherrill wrote:
> i386-rtems tools do not include long double math routines but Cygwin
> does and there is a comment in math.h indicating they have code
> elsewhere for these.
> Are these OK to use to fill in the long double gaps?

Cygwin just uses straight newlib/libm, and the BSD versions of those long double
math functions are already in newlib/libm/*/*l.c and available on Cygwin: sizeof
float80, float128, and long double are all 16.
There are also some x86 asm and fast math specializations under winsup/cygwin/math/
Or are you talking about other long double math functions not included?
You should be able to persuade configure to build RTEMS newlib/libm with a heavy
platform config supporting long double size 16 and excluding _LDBL_EQ_DBL.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
Reply | Threaded
Open this post in threaded view
|

Re: i386 long double math methods

Joel Sherrill
On Thu, Sep 26, 2019 at 12:24 AM Brian Inglis
<[hidden email]> wrote:

>
> On 2019-09-25 16:06, Joel Sherrill wrote:
> > i386-rtems tools do not include long double math routines but Cygwin
> > does and there is a comment in math.h indicating they have code
> > elsewhere for these.
> > Are these OK to use to fill in the long double gaps?
>
> Cygwin just uses straight newlib/libm, and the BSD versions of those long double
> math functions are already in newlib/libm/*/*l.c and available on Cygwin: sizeof
> float80, float128, and long double are all 16.

On RTEMS i386, long double != double and this code is disabled so we end up
missing the entire set of long double methods. That's what I am trying
to resolve.

> There are also some x86 asm and fast math specializations under winsup/cygwin/math/
> Or are you talking about other long double math functions not included?

Thanks. I need to move these to newlib/libm/ when I finish the fenv.h.

BTW and please, do you see what's wrong in my fenv.h patch for x86_64? I would
really like to wrap that up and move on to something else. :)

> You should be able to persuade configure to build RTEMS newlib/libm with a heavy
> platform config supporting long double size 16 and excluding _LDBL_EQ_DBL.

As I said earlier, long double != double on this target and this code
is disabled.
I suspect most i386 and x86_64 newlib targets are missing the same math methods
unless they provide them special like newlib.

Thanks for the pointer to winsup. I will move those to newlib once the
fenv.h patch
is resolved.

--joel

> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
Reply | Threaded
Open this post in threaded view
|

Re: i386 long double math methods

Brian Inglis
On 2019-09-26 07:23, Joel Sherrill wrote:

> On Thu, Sep 26, 2019 at 12:24 AM Brian Inglis wrote:
>> On 2019-09-25 16:06, Joel Sherrill wrote:
>>> i386-rtems tools do not include long double math routines but Cygwin
>>> does and there is a comment in math.h indicating they have code
>>> elsewhere for these.
>>> Are these OK to use to fill in the long double gaps?
>>
>> Cygwin just uses straight newlib/libm, and the BSD versions of those long double
>> math functions are already in newlib/libm/*/*l.c and available on Cygwin: sizeof
>> float80, float128, and long double are all 16.
>
> On RTEMS i386, long double != double and this code is disabled so we end up
> missing the entire set of long double methods. That's what I am trying
> to resolve.
>
>> There are also some x86 asm and fast math specializations under winsup/cygwin/math/
>> Or are you talking about other long double math functions not included?
>
> Thanks. I need to move these to newlib/libm/ when I finish the fenv.h.

BEWARE:

/* ...  On Cygwin the long double functions
   are implemented independently from newlib to be able to use optimized
   assembler functions despite using the *Microsoft x86_64 ABI*. */

> BTW and please, do you see what's wrong in my fenv.h patch for x86_64?
> I would really like to wrap that up and move on to something else. :)

Sorry, not good with autotools, but something must be undefined to or in
NEWLIB_CONFIGURE, and I'm suspicious of ././config.cache and
../../.././config.cache given message: line 1679: syntax error near unexpected
token `../../..'

>> You should be able to persuade configure to build RTEMS newlib/libm with a heavy
>> platform config supporting long double size 16 and excluding _LDBL_EQ_DBL.
>
> As I said earlier, long double != double on this target and this code
> is disabled.
> I suspect most i386 and x86_64 newlib targets are missing the same math methods
> unless they provide them special like newlib.

Should be enabled if $(CC) <float.h> defines LDBL_MANT_DIG != DBL_MANT_DIG and
long double compiles. May want to --enable-newlib-io-long-double.

> Thanks for the pointer to winsup. I will move those to newlib once the
> fenv.h patch is resolved.

BEWARE:

/* ...  On Cygwin the long double functions
   are implemented independently from newlib to be able to use optimized
   assembler functions despite using the *Microsoft x86_64 ABI*. */

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.