Re: Deciding new arm EABI port name
On Thu, Mar 30, 2006 at 03:07:16PM +0100, Martin Guy wrote:
> > Isn't FPU something more related to the CPU rather than LIBC or ABI?
>
> Yes and no. There are many interrelated questions.
Sure, choosing a FP method (softfloat, FPA, VFP etc.) relates
to the binary instance of a certain C library (should be compiled
with the same FP method), but it should not relate to the choice of
which library to use. That is, packages from arm-softfloat-linux-gnu
would be just as incompatible to arm-softfloat-linux-uclibc as
to arm-vfp-linux-gnu.
(Not knowing too much about EABI) I would assume that EABI is
more than a way to link softfloat and FPA/VFP objects... If it is
no more than that, then softfloat, fpa (default), vfp should be
mutually exclusive. Otherwise, ABI should be an additional property
of the architecture.
>
> 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...
Thanks for info, I'll look into the ARM ABI docs in more detail...
>
> M
>
Reply to: