From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18603 invoked from network); 27 Dec 2021 18:04:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Dec 2021 18:04:53 -0000 Received: (qmail 5898 invoked by uid 550); 27 Dec 2021 18:04:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5863 invoked from network); 27 Dec 2021 18:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640628279; bh=i+bQdSRquZajnirqIpBKPtUkImO4h92mRbIR0x4QYNU=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=OvVGO86SA/28meeveoa1my/075gcZYzPt3CE/xmOBpgA+LkUSHqkhJqdBiufIo5vZ /VsQfjsnEjCwRX09aZMhtYbnYriCthqP/gSDgiYatZkwqOYgx29wZx6LQwnpt/+73L 1L9wM18wzuztK0pi6PXNneGuMptFij2SbtiRg84M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 27 Dec 2021 19:04:37 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20211227180437.GE1949@voyager> References: <20211226204238.GA1949@voyager> <20211227150010.GU7074@brightrain.aerifal.cx> <20211227163056.GV7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211227163056.GV7074@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:QpyAgUkP0OXs4/yfq5zwRCD3eaQN0PTji3qDrNVA4WqseX8pt9E WX5uKQX93G/SP5Nnz3rpMcVIhj815MMsReV41t/ogfSzz9SCOcbvA7iZmS6iZRoJrcNGc/Q vvZJvRfrhlUWlFlaY6j28cIRo8UpWT6uv/P6z7mUVUs/UDI2oBpiuBDkGKKbuA37iMWCNNU yUAP4IYvUI0p8BHcOChRA== X-UI-Out-Filterresults: notjunk:1;V03:K0:JzXBC39iAa4=:PsVl5hpgeoGW2SnOPk3xNc 1U7nMg7znAP8VCMOPew3UMcF2agyeai5ybZdOLNuuKiqz5AxKLupOAvZdLVswa2qdJbQO+dy1 fAPstAd68binv8aRFLVh7M754LCBU8BrDVkbu5q+O8VcTC/r8+z6RkJuywa4Fmc5In+l80P+k bQNMfS3Mw9DtA7XsAdzS8ut9SyqOw7SzSlv4+GBQq9sNtVMJSZWw0OJcoFDstpVHdZj2AMZsL +AQviSaxPTlXzSjqilT+4vc5/b8X2H6P9Qk0hBVtFxjLYLgfVWWx+VNJ0uxi9QtmDocN0R+L6 LCfIkbg4qlFhwUW+ygLrX5Zc5sBXqwEvcCBzn2CCNlGO3eYLO0C5FaZtoJcnffULHIugVeMNa tUsw3kY9Dm/dl2l+tHbAu1N4kKAIOD9XIMDXBVx8myCb6KMBx212057j2+19Jcqe5l3e7c+Vu Cvkm0CMT0avnRyDOt7tTcWT6rUZfucJ+QUEwI5x90DYbI7UvwE31+ZrSR0yV0IOsWAHT6DT09 lyU1W1DBgQC8tJfpHVzTP9W2wVKqc95cWsan7PjdWHziwlgkCCNQvPdQRh3cXPkL5PElcHwYS sbboNlt0anyKwKR9JIRM/G/ZAP6+NaVOEFUv0Vo4Ws4MzI3wbh7ZRZxF3kH5IJqrD8Wpqy6wm H+LgXlb6YGIa0VPw3cJxi6V7rjuO8nTu/Q4kyK9WmFteZcrApa21mHCFTsbB0bir6DZ7tPidA x2AuajEez/9ODa6nNQ3N08QJ4ulDs2QK9WsIB12+G6rNWwIBAJ/DpxmHWa1dLSpf2CRzX9otQ G/yDhsaehsYKJGqamomMLbFnQH1/edf25/Q1D1H32ON3CHvNpXZ4/WiAhEhdT3N9hEpDZCqTf TvHlarZT2lJ9aaR2QVvfZikpEwBzbqW5p1nwMAmjo16RpSaxo54dkg5fBDxLXb2WrycSNDf8v 0cYxJfaqNqlusWFmszH+XfozgJJz9CIHeGvmUxL2TQw0mM7vcgqC/sbuch7npxX4neDn1eiH0 0drgr9rLkLlhXoEYzkl+6vkQy6UZbeXi4wI0G4Pzx5BfryPNFsvO4Mrt84kHU4ohu45Ns0aHA FiEaDEwfjL7wG0= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] ASM-to-C conversion for i386 On Mon, Dec 27, 2021 at 11:30:56AM -0500, Rich Felker wrote: > 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) > That comment was copied from acos.s. In general, I have tried to preserve comments. Except in fenv.s, where each time __hwcap was tested, the same comment was prefixed, and its point should be coming across ten times more easily by just creating a symbolic constant. > 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 > "=3Dt"(x), x have type long double). > That's probably an even better idea than what I am currently doing: Moving the "core" functions into a new header file (as static inline functions), and using these in the function implementations. I could not get all the duplication out; in some cases the duplication is only conceptual (hypot() and hypotf() have the same idea, but it needs to be implemented differently due to the different precisions/representations). I think I can combine both approaches, because what I'm doing appears to have the effect of moving the __asm__ statements entirely out of the C files into the new header file. And it appears that we are only using a couple of instructions, anyway. Downside is that implementing static inline long double x87_fabs(long double x) { __asm__("fabs" : "+t"(x)); return x; } now actually carries the connotation that the result is of double-extended precision and needs rounding before being returned. Unlike the current version which does not do that. However, to my knowledge that will not actually be wrong, only slower, so a solution that preserves the current connotations for these few instructions can probably be considered a micro-optimization. Ciao, Markus