Re: Deciding new arm EABI port name
On Sun, Apr 02, 2006 at 10:57:23PM -0700, Daniel Gimpelevich wrote:
> 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
As was explained consistently with my experience, you can not mix
binaries compiled with -mhard-float and with -msoft-float, as well as
ones compiled with -msoft-float -mfpu=vfp with -msoft-float. There is
a flag in the object (look for private flags in objdump -x) that
prevents linking objects with incompatible ABIs.
> 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?
EABI is probably the answer to all those issues...
>
>
> --
> To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: