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