Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 3 Mar 2012 23:57:58 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libm

see
http://nsz.repo.hu/libm

i put together a libm using the freebsd libm
and some code from openbsd

i did various useless code formatting cleanups
as the code was in bad shape (we will have to
rewrite some parts anyway, so it is not that
important to keep fdlibm diffability, instead
i recorded the date of the freebsd and openbsd
source tree checkout so we can see if they fixed
something since then)

the // FIXME and TODO comments are from me
(i did not mark all the issues, i got tired after a while)


notes:

the source contains parts of musl to make testing/building
easy

i modified math.h and added complex.h and tgmath.h
(although i'm not sure about the later, it uses c11)

i already rewrote some simple functions when they were
incorrect (ilogbl) or overcomplicated (fmax, logb)

internal stuff is in libm.h which includes math.h
and float.h so every .c just includes libm.h

long double is handled in an ugly way now:
ldhack.h contains all the ld macros and unions
that is used in the *l.c functions
for my convenience i defined LD64, LD80 and LD128
there and just used these with #if directive

complex is missing

tgammaf, tgamma is missing
(the only 3clause bsd licensed code)
(cephes lib has another implementation)

i added frexp from musl stdlib for completeness

i did some testing of the double functions
using crlibm and ucbtest testvectors
and so far things seem fine
(pow has some issues in certain corner cases
and it seems x87 hardware sqrt is not correctly
rounded eventhough ieee requires it to be,
or maybe it's another double rounding issue)


questions:

keep frexp in stdlib?

how to do the long double ifdefs?

check x87 fpu precision setting from ld80 code?
(or we assume it's extended precision)

preferred way of handling consts?
(freebsd code uses 1.0f, (float)1, 0x1p0, static const float one=1;..)
(i'm not sure why 'one' or 'zero' is used instead of 1 or 0
maybe it's another compiler float-store bug workaround)
i assume (float)1.0 is the same as 1f

i wonder if it's ok to use a polyeval(coeffs, x) function instead
of writing out the polynomial (some openbsd long double code uses
such thing but not everywhere)


todo:
- move the code to musl tree so the changes are recorded there
- fix int32_t issues (there are many)
- define isnan, signbit, etc macros to be efficient and
change bithacks into isnan etc in the code when appropriate
- fix extended precision issues (probably only fma)

there are lower priority tasks:
use scalbn instead of ldexp in internal code (ldexp is a wrapper)
clean up hard to follow control flows
fix invalid comments
clean up long double code
use consts consistently
make proper libm test suit

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.