Message-Id: <200005151608.MAA16530@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: djgpp-workers AT delorie DOT com
Date: Mon, 15 May 2000 19:17:42 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: Re: Math functions
In-reply-to: <39200DC6.B952CF67@cyberoptics.com>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id MAA16532
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 15 May 00, at 9:46, Eric Rudd wrote:

> 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. 

I have seen that, and was impressed.

> 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'll think about this. Maybe, even some mocros would help in 
assembler source. There is one complication though, compared to the 
double functions. The arguments can be unnormal with long double, 
which is not possible with double.

> 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.

Of some important functions, the execution speed can be quite 
comparable. Logl should be the same, expl, exp2l and exp10l should be 
not much slower, because the argument reduction code will at most 
need a few FPU instructions.

> As I read this, none of the "long double" routines will be affected, since they
> don't exist in C90.  

Sqrtl will be inlined by the compiler. I think, most of the other 
functions shouldn't be inlined.

-- 
Regards, Dieter Bürßner