Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Dec 2021 11:30:56 -0500
From: Rich Felker <>
To: Markus Wichmann <>
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).


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.