From owner-freebsd-hackers Fri May 31 09:13:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21340 for hackers-outgoing; Fri, 31 May 1996 09:13:09 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA21324 for ; Fri, 31 May 1996 09:13:04 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id QAA03669; Fri, 31 May 1996 16:13:03 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma003663; Fri May 31 16:12:35 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.12/8.6.9) id JAA21266; Fri, 31 May 1996 09:12:35 -0700 Date: Fri, 31 May 1996 09:12:35 -0700 From: "M.R.Murphy" Message-Id: <199605311612.JAA21266@meerkat.mole.org> To: bde@zeta.org.au, freebsd-hackers@FreeBSD.org, mrm@MARMOT.Mole.ORG Subject: Re: TARGET_NO_FANCY_MATH_387 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Might it be a good thing now to change the default in gcc to enable > >FP sin, cos and sqrt. > > It would only give the inline sqrt. The inline sin and cos are disabled > in the FSF version of gcc-2.6.3 for other reasons. At least the i386 > versions of them were broken. You can use -mfancy-math-387 to get the > inline sqrt and -ffast-math to get the inline sin and cos together with > other fast and broken "math", or you can use inline assembler to get > inline math functions exactly where you want, or you can use the i387 > version of libm to get non-inline hardware math functions in more cases. Agreed. I was suggesting a change in default behavior. > > >'387's have come down a fair amount in price > >for those of us with trusty '386/16's. Those still dependent upon > >FP simulation could use -mno-fancy-math-387... > > The price of an i386 sqrt() emulation (in milliPentiums :-) has gone > up. Those dependent on FP emulation would probably have difficulty > bootstrapping to use it. At least the following utilities use sqrt(), > so they might fail when their inline sqrt() doesn't work: as, awk, bc, > cc1, cc1plus, dc, gdb, groff (parts), perl. And your last sentence says why it's not a Good Idea to change the default behavior. Also agreed, and I withdraw the suggestion. Too bad, though. And I expect that just adding the same (no, similar, not the same, no GPL, no LGPL, I'm sorry) non-optimized software sqrt, sin, cos that are in the normal libm to the emulator would be not so good. Or maybe it would be good? Then changing the default might be a Good Idea. I'll restate the suggestion. Otherwise I guess it's a manual edit of the definitions and a make world. Or make the make world have a way to set the definitions in conjunction with the bsd.h file deep in gcc's bowels. Nahh, too kludgy. Now for the cheap-shot, flame-bait, no-good comment: the reason that this came to my attention at all was to figure why a program ran so much faster on ... Linux. Ayeeee. Yeah, I know which FPE they use :-) And with the switches to the compiler set "right", the program ran the same speed on the same hardware independent of OS. Not unexpected. > > >and document > >-mfancy-math-387, -mno-fancy-math-387 in the man page for cc? ;-) > > They have been documented for 5 months in -current, and the changes were > merged into -stable a couple of days ago. > Prescient. :-) -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good