Re: Deciding new arm EABI port name
> Isn't FPU something more related to the CPU rather than LIBC or ABI?
Yes and no. There are many interrelated questions.
There is the physical FPU that a particular user has in their
computer, which is currently one of:
none, FPA, VFP, MaverickCrunch or iWMMXt (not really an FPU they tell me)
all of which have add different sets of instructions to the ARM integer ones,
further complicated that FPA has a different FP data format than the others.
Then there is the way that floating point mathematics is carried out
by the software, which can be one of (with relative speeds):
- real FP instructions processed by one of the FPU hardware units (speed: 77)
- real FP instructions emulated using basic ARM instructions in the
kernel (the current Debian arm method uses this: real FPA instructions
emulated in the kernel) (speed: 1)
- real FP instructions emulated in userland by catching the SIGILL
that the kernel can generate (not used in Debian: would be even
slower)
- a compiled-in library of routines using ARM instructions that carry
out the FP calculations (known as "soft-float") (speed:7)
Lastly there is the "FP model" that a debian architecture uses,
composed of the floating point format and the default choice between
the above four methods.
Quite a lot of different possibilities are generated by the different
FPU instruction sets/formats and different implementation mechanisms,
and some people, understandably, want to use a debian distribution
that gets the very most out of their particular hardware.
However, that is not among Debian's aims (it is Gentoo's though).
Debian aims to produce as few precompiled binary distributions as
possible that work on as much hardware as possible. At the time it
started, FPA was the only ARM hardware FPU, and kernel emulation of
FPA instructions would work on any FPA-less ARM processor. Sadly, it
has turned out to be a duff choice, since modern ARM FPUs neither run
the FPA instruction set nor even store FP values in the same format as
FPA (They use the IEEE storage format, as does the soft-float option).
So part of the point of moving to ARM EABI is to move to an ABI that
allows us to distribute binary packages that will still run on
everything (well, everything down to the armv4 family anyway) but
still allow people with FPUs to recompile single packages to use the
real FP hardware they happen to have - something that is not possible
with the current ARM Debian distribution. The new ABI allows mixing of
soft-float and hardware FP instructions within an executable (or more
precisely, allows you to link a mixture of soft-float and hard-float
object files) so one solution would be to compile all Debian packages
by default with IEEE soft-float (the medium-speed of the three
mechanisms currently in use) which would then allow people to
recompile the packages for their speed-critical applications and
libraries to use the specific hardware they have, rather than having
to rebuild the entire distribution just to be able to use your FPU.
At least, that's my understanding of it at the moment...
M
Reply to: