[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120304065340.GT184@brightrain.aerifal.cx>
Date: Sun, 4 Mar 2012 01:53:40 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com, nsz@...t70.net
Subject: Re: libm
On Sat, Mar 03, 2012 at 11:57:58PM +0100, Szabolcs Nagy wrote:
> see
> http://nsz.repo.hu/libm
Some initial questions...
- Why are there two versions (one "slow") of rem_pio2?
- Is __invtrigl.c used? It clashes with the app-reserved namespace.
> 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)
Sounds fine to me.
> i modified math.h and added complex.h and tgmath.h
> (although i'm not sure about the later, it uses c11)
There's an old gcc way to do tgmath.h without c11, but it's full of
gcc-specific hacks involving __typeof__. If gcc4 allows _Generic even
with -std=c99 etc. then I think _Generic is the best.
> questions:
>
> keep frexp in stdlib?
It's ok to move it. I had it there from back when there was a separate
libm because printf depends on it.
> how to do the long double ifdefs?
#if LDBL_MANT_DIG == ...
> check x87 fpu precision setting from ld80 code?
> (or we assume it's extended precision)
All existing code (well, mainly macro definitions) in musl assumes its
set to extended, and we provide no code to change it.
> 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 like 1.0f, etc. BTW are you sure 1f is valid C? Certainly 1L is not
a valid alternative for 1.0L when you want long double..
> 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)
I suspect the functions that aren't using it right now depend on a
particular evaluation order to avoid loss of precision. I could be
wrong though; that's just my best guess.
> todo:
> - move the code to musl tree so the changes are recorded there
Very interested in doing this sooner rather than later.
> - 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
Try something like:
union __float_rep { float __x; uint32_t __r; };
#define __FLOAT_REP(x) ((union __float_rep){x}.__r)
#define isnan(x) \
sizeof(x)==sizeof(float) ? (__FLOAT_REP(x)&0x7fffffff)>0x7f800000 : \
sizeof(x)==sizeof(double) ? (__DOUBLE_REP(x)&....
Does that work? Of course it would work to just let it get converted
up implicitly to long double and just have one case, but that would be
more expensive I think.
Rich
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.
