[Top] [All Lists]

Re: NON FPU cpus - way to go

To: "Maciej W. Rozycki" <>, "Jun Sun" <>
Subject: Re: NON FPU cpus - way to go
From: "Kevin D. Kissell" <>
Date: Thu, 8 Feb 2001 11:52:01 +0100
Cc: "Alan Cox" <>, "Florian Lohoff" <>, <>, <>
References: <>
> On Wed, 7 Feb 2001, Jun Sun wrote:
> > I favor the libc approach as it is faster.
>  No difference in speed, actually.  In both cases you switch to the kernel
> mode when an FPU-related exception happens and then back to the user mode,
> either after or before invoking the handler.  The libc approach has the
> advantage of running unprivileged.

Do you have some numbers to support this?  A proper library
implementation does *not* trap to the kernel on each FPU
instruction, and as such is considerably faster (and considerably
larger - a factor for embedded apps!) than a kernel emulation.
The Algorithmics emulator does have the virtue of being smart
enough to check if there is a sequence of consecutive FP
instructions, and to emulate the whole sequence without
returning to user mode, but such "runs" are not all that
common in real code - there are almost always loads,
stores, and address computations interspersed, because
the compiler is "clever" about hiding FP latencies!

> > Unfortunately I don't think glibc for MIPS can be configured with
> > --without-fp.  I modified a patch to get glibc 2.0.6 working for no-fp
> > but it is not a clean one.  Is anybody working on that for the latest
> > 2.2?
>  You never want to configure glibc with the --without-fp option.

That's certainly what we had to do for OpenBSD without FP
emulation!  What is the alternative?

> > Ironically for MIPS you MUST have the FPU emulater when the CPU actually
has a
> > FPU. :-)
>  The same for Alpha.  You don't need a full emulator anyway -- most of it
> can be left out for FPU-equipped systems.

That may be true for Alpha, but not for MIPS.  The only
instructions that can *never* generate an unimplented
operation trap on a denormalized operand are the
loads, stores, and moves.  That's why we didn't bother
breaking up the Algorithmics emulator into with-FPU
and without-FPU modules - there was surprisingly little
that could really be left out.


            Kevin K.

<Prev in Thread] Current Thread [Next in Thread>