Before you get too much time invested, I would stop and look things
over. It may be the trap overhead is causing the slowness, but that
would surprise me unless you are doing a huge amount of floating point.
What is more likely in my experience is that the emulation itself is
slow. Changing from a runtime (trap) mechanism to a called library
isn't going to significantly change that. I've been told, and verified
on one occasion, that the primary difference between a fast flpt
emulation and slow one is the quality of the libraries.
IMPORTANT NOTE: The C language defines all floating point math to be
DOUBLE PRECISION. The definition of a single precision operation (with
an extreme example):
{
float a,b,c;
c = a * b;
}
is to promote both a and b to double precision, do the multiply, and
then convert the result back to single precision and store it in c. To
literally obey the C spec, a floating point emulation needs only double
precision algorithms because a "by the rules" C compiler doesn't use
single precision other than load, store, and convert to/from double.
Slow emulation libraries are quite often slow because they do a literal
emulation of the floating point coprocessor and do all the math in
extended (double?) precision, cutting the result down to size. If you
are doing a lot of single precision flpt, this is very expensive. Slow
libraries also may be doing more in terms of validity checking (again,
doing a better job of emulating the fltp coprocessor and implementing
the IEEE spec properly).
Also, if you use any transcendentals (sin, cos, log, ln, etc.), there
are _huge_ speed differences in figuring out a solution to enough
precision for single versus double or extended precision. There are
also algorithms available which converge faster than traditional
transcendental algorithms but always with some sort of tradeoff (unless
your floating point emulation is really stupid, but that is rarely the
case nowdays).
Fast emulation libraries typically are faster because they cut corners
with the emulation, making them (by the measure of precision and
accuracy) actually _worse_ libraries. The primary corner cutting is to
do everything in single precision. This can make a significant speed
difference if the accuracy tradeoff is acceptable in your application.
gvb
At 06:53 PM 6/15/00 -0500, Pawan Singh wrote:
>Has someone already done this and willing to share? If not, I will have to
>do it and I am willing to make it open-source.
>
>-Pawan
>
>-----Original Message-----
>From: Keith Owens [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, June 15, 2000 4:12 PM
>To: Pawan Singh
>Cc: [EMAIL PROTECTED]
>Subject: Re: Math emulation on Linux very slow??
>
>
>On Thu, 15 Jun 2000 18:00:53 -0500,
>Pawan Singh <[EMAIL PROTECTED]> wrote:
> >I tried compiling with -msoft-float option and I start getting linker
> >errors for functions like __muldf3, __adddf3, etc...
> >
> >The MAN page states that GCC does not provide these functions. (even
> >though I am building for 386).
>
>Grab the math-emu code from the kernel and make it a library.
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
