Date: Mon, 15 May 2000 09:46:30 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: Math functions
To: djgpp-workers AT delorie DOT com
Message-id: <39200DC6.B952CF67@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.72 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <200005121101 DOT HAA05022 AT delorie DOT com> (buers AT gmx DOT de)
 <200005131046 DOT GAA30179 AT delorie DOT com>
Reply-To: djgpp-workers AT delorie DOT com

Dieter Buerssner wrote:

> Anyway, in my other mail, you can see, that I already tried to set errno. The
> problem are assembler only functions, where it IHMO really needs a lot of bit
> twiddling, that I can do much easier in C. A maybe acceptable alternative
> would be, to check the arguments in C code, and call then an assembler
> function, that does the calculation. Inline assembly unfortunately won't work
> in many cases.

I found that the tests were actually pretty easy in assembler;  in C, you have
to do some ugly casts or unions to get at the bits, but in assembler, you just
load parts of the word into the CPU and do integer operations on them.  In my
"double" routines, I biased the tests in favor of normal arguments.  That is, I
made normal arguments fall successfully through as few tests as possible,
generally with branches not taken, so that for normal arguments (which one
would expect 99.9% of the time), the execution is as fast as possible.  In the
exceptional cases, one can do more elaborate tests to sort them out.  If I were
coding "long double" routines, I would try to use the existing tests with mild
adaptation.

I think that execution speed is less important for "long double" functions,
because if one is in a hurry, one generally would use the "double" functions
instead, but I think the exception tests could be made almost as fast as in the
"double" routines.

> > AFAIK, the latest version of GCC emit inline code for many standard
> > math functions.  I'm positive about `sqrt' and `exp',  but I'd expect
> > some others, like `sin', `cos', and `atan', to be handled in a similar
> > way.

According to gcc.i1:

     `-fno-builtin':
     Don't recognize builtin functions that do not begin with
     `__builtin_' as prefix.  Currently, the functions affected include
     `abort', `abs', `alloca', `cos', `exit', `fabs', `ffs', `labs',
     `memcmp', `memcpy', `sin', `sqrt', `strcmp', `strcpy', and `strlen'.

As I read this, none of the "long double" routines will be affected, since they
don't exist in C90.  The question I have is what happens to the type-generic
function macros specified in C99, since they have the same names as the
"double" routines.  This may be something we have to take up with the gcc
maintainers.

-Eric Rudd
rudd AT cyberoptics DOT com