[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Dec 2021 11:30:56 -0500
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: ASM-to-C conversion for i386
On Mon, Dec 27, 2021 at 10:00:11AM -0500, Rich Felker wrote:
> On Sun, Dec 26, 2021 at 09:42:38PM +0100, Markus Wichmann wrote:
> > For the maths code,
>
> One thing I found right away on the math code: You can't use "=t" for
> output in a float or double variable unless the asm naturally
> guarantees there's no excess precision (e.g. fmod where the operation
> is exact and the precision is necessarily bounded by the input
> precision). Otherwise you need "=t" to a temporary long double output
> to then let the compiler convert down to float or double (e.g. at time
> of return; I think we're still using explicit cast there too in case
> some compilers get this wrong).
One thought, and I'm not sure if this is a good idea or a bad one but
worth discussing:
Using your acos.c as an example, where you have the comment:
atan2(fabs(sqrt((1-x)*(1+x))), x)
The actual code could be written as:
return (double)x87_fpatan(x, x87_fabs(x87_fsqrt((1-x)*(1+x))));
with the appropriate "x87.h" defining each of these with the
appropriate asm & constraints. This kinda makes the individual
functions self-documenting and non-error-prone (repetition of
error-prone constraints, especially the hidden requirement that, in
"=t"(x), x have type long double).
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.
