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.