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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
