The 2012 Kernel Summit [LWN.net]

The 2012 Kernel Summit

Posted Sep 11, 2012 3:34 UTC (Tue) by dlang (guest, #313)
In reply to: The 2012 Kernel Summit by BenHutchings
Parent article: The 2012 Kernel Summit

> e.g. building without using the FPU at all)

Isn't that what softfloat vs hardflat is? softfloat is software floating point (i.e. no FPU) while hardfloat is using the hardware floating point engine (i.e., use the FPU)

to post comments

The 2012 Kernel Summit

Posted Sep 11, 2012 5:23 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Isn't that what softfloat vs hardflat is? softfloat is software floating point (i.e. no FPU) while hardfloat is using the hardware floating point engine (i.e., use the FPU)

Not if you're referring to the ABIs, which are the fundamental difference between what dpkg calls armel and armhf. The soft-float variant of ARM EABI (armel) requires that FP parameters and return values are passed in integer registers, for compatibility with FPU-less processors. Functions built for the soft-float ABI may still use an FPU if present, but they have to move values between integer and FP registers at call boundaries. The benefit of the hard-float ABI (armhf) in terms of code generation is that it uses the FP registers for parameters and return values, reducing the need for register moves.

Of course, targetting armhf does mean all code can be built to assume an FPU is present, without the need to provide a fallback for less capable processors. This is simpler in some ways as there is no need to do run-time CPU checks in executables, and no need to build multiple variants of libraries. But looking at this from a higher level again, adding optimised libaries to Debian's armel should mean less work in the long term for Raspbian...

The 2012 Kernel Summit

Posted Sep 11, 2012 8:21 UTC (Tue) by Jonno (guest, #49613) [Link]

The biggest difference between armhf and armel is that what an armhf compiler would have compiled into a single floating point instruction, an armel compiler will instead make into a function call.

On a floating point capable system that function will only be three instructions long (copy the arguments from integer registers to floating point registers, the actual floating point instruction, copy the result from a floating point register to an integer register), while on other systems the function will contain a complex emulation instead.

Thus, even armel will make use of the floating point capabilities of a processor that has one, but it will do so in an inefficient manner (for every instruction, add a function call and two register copies).

If a single user function contains many floating point operations, it is possible to minimize this cost by compiling two versions of it for armel, one that internally uses floating point instructions directly, and one that internally uses the standard emulation functions. That way you only have to pay the extra cost when crossing user-function-borders, rather than for every instruction. This can either be done on a function-by-function basis by the application developer, or on a library-by-library basis by the distributor (which is what Ben refers to). Adding such an alternative library for every fp-using library in Debian would have netted almost as large a benefit as that of Raspbian, without the need of forking the entire distribution, but I wouldn't want the job of trying to convince ~100 package maintainers and the release team that it was a worthwhile feature to add to wheezy in the middle of the pre-release freeze...