Re: armelfp: new architecture name for an armel variant
+++ Hector Oron [2010-07-06 19:30 +0200]:
> " There are 3 ABIs in armel right now, regarding the use of the fpu: a) soft (no
> fpu used, all fpu math is done software only, using libgcc fallback
> functions), b) softfp (the fpu is used, but function arguments are passed
> through the integer registers and not the fpu hardware registeres, this
> results in unnecessary register moves for every function call that uses
> floating point argumetns, c) hardfp, argument passing is properly done using
> the fpu registers directly. The result is estimated to save 20 CPU cycles per
> function call. Not something to ignore esp. given the embedded nature of ARM
> where every cycle is important.
>
> These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}. Softfp
> is the default in pretty much every distro out there (incl. Ubuntu, Debian,
> etc). Only some OpenEmbedded builds have enabled hardfp, but these are too
> specialized.
>
> Don't ask me why this was so, I don't know the historical reasons for having
> this behaviour in ARM cpus.
The reason is that softfp will work on devices with and without FPUs.
hardfp only works on devices with fpus, whilst still allowing the
optional use of FPU units when present. So for a binary distribution
it makes sense as the most general option.
> So... here is the story so far. I now have 9 efikamx systems here, waiting to
> be used as a buildd cluster, but I have wanna-build which just busts my balls
> and just won't install.
That is most people's experience of wanna-build.
Re the overhead, I have been told that it is significant on cortex-A8
(which I believe the efikamx is) but will be much less so on A9
processors. That might mean it ceases to be worth maintaining a port of
hardfp beyond A8.
There are of course many possible ABI, FPU and instruction-set options
possible on ARM (far too many in fact). Which ones it is worthwhile
supporting in Debian is an interesting question. It would be good to
keep the number of incompatible architectures as low as possible and
use other mechanisms to allow the use of CPU features when present.
There are fields in the elf headers to indicate cababilities used in a
binary which are not currently used by the compiler which would help
in automatically ensuring that CPUs do not try to run code they can
(because it has FPU or NEON instructions and those units are not
present, for example). Toolchain and loader changes are needed to make
that a reality, but that's better than an explosion of
'architectures'.
Having two arches: for the incompatible softfp and hardfp ABIs makes
sense.
The use of other options (VFP, NEON, newstuff) and the use of Thumb2
(arm v7, some v6 CPUs) can hopefully be done in a compatible way, but
clearly each of these things only works on CPUs which support them.
VFP, NEON and thumb2 can all provide significant speedups on the right
hardware. Providing a good way to build alternatives for CPUs
with/without these facilities (in the packages where it matters) and
have the package manager just 'DTRT' would be a good thing.
Some of this is considered here:
https://wiki.ubuntu.com/Specs/M/ARMDpkgWishlist
(in 'capabilities')
As to the arch name, 'armelfp' is not ideal. It implies that armel
doesn't do fp. Of course if the default builds are for 'softfp ABI
with no VPF instructions' (=armel) and 'hardfp ABI with VFP
instructions' (=armelfp) then I guess that gives the right idea, but
this could change, and ports are long-lived.
armelhf would be clearer about what is different: the hard-float ABI.
That would be my vote. Which capabilities are enabled in the default
build of an architecture can change (slowly) over time as we decide no
longer to support very old hardware, so it's best to pick a name which
should continue to make sense over time.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: