Re: FP transition
On Thu, Sep 29, 2005 at 11:28:28AM -0700, Peter Naulls wrote:
> I'm familiar with the issue of SF vs HF as are many of the people who've
> been working on ARM for a long time. But perhaps for the benefit of
> those who aren't too familiar with why the change is needed and what
> advnatanges it would bring, plus the interaction with big endian, can
> someone do an outline of the issue? I don't think I'm personally the
> best person to prepare such a thing.
Well I am certainly no expert on it. Here is my understanding of
Some arm processors (mainly in the past) had FPUs on them (So they could
do floating point calculations in hardware fairly quickly). Most arm
processors later have not had any FPU so instead you either have to let
the compiler convert all floating point calculations to integer
operations using a softfloat library or other equivalant conversion, or
you can keep the floating point code in the program and have the OS trap
on unsupported instructions (FP instructions in this case) and emulate
them in the kernel and continue the execution of the program after
finishing the emulation. The debian arm little endian port currently
uses the kernel floating point emulation.
The advantage of the kernel floating point emulation is that if your cpu
does have hardware FPU, it is used, and otherwise it is emulated in the
kernel and the same binary application runs on both, gaining the speed
advantage if you have the hardware FPU.
The advantage (I believe) of using a softfloat implementation instead is
that it is able to use more efficient optimizations at compile time
because it has more information (from parsing the original source) about
what the calculation is needed for and what precision is necesary, etc.
It can take shortcuts the full emulator can't, since the emulator must
do whatever the hardware FPU would have done or risk being incompatible.
Since most modern arm systems don't have an FPU (at least as far as I
have been able to tell), gaining performance from using softlib instead
of the fpu emulator would be nice. arm systems are usually not the
fastest machines around to begin with after all.
You can't mix binaries using softfloat and hardfloat though since they
use different calling conventions for passing the floats around if I
understand things correctly, meaning you can't just compile some things
one way and leave the rest the other way and get away with it, except
for the kernel which probably doesn't care as long as it has the fpu
emulator enabled in case anything tries to use hardfloat calls.
Someone please correct my mistakes, since there probably are a few.