Re: Deciding new arm EABI port name
On Thu, 30 Mar 2006 15:07:16 +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.
>
> 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
This may very well be a nauseatingly unworkable suggestion, but for the
old ABI, it seems to me the most optimal compromise can be achieved if
everything used a shared-object soft-float library that could be swapped
out and replaced with whatever work-alike would be most speed-efficient on
the individual machine. The standard library would use basic ARM
instructions to implement the soft-float API and data types, while one
drop-in replacement could use FPA instructions to emulate the same thing
and convert data types on the fly, another could use VFP instructions with
no conversion, etc. Other ABI inadequacies notwithstanding, is this really
less trivial to do than replacing the ABI wholesale with something less
backward-compatible?
Reply to: