Linaro ARM hardfloat support

What is hardfloat?

For ARM there exist 2 forms of the EABI right now, soft/softfp and hard. These are passed to gcc using the option -mfloat-abi=soft/softfp/hard, resp. 'soft' is not using the FPU at all and using gcc math replacement functions to emulate floating point arithmetic. 'softfp' is using the FPU but arguments to functions are being passed through the integer unit, that is into integer registers and from there moved to the floating point unit. 'hard' is using the FPU typically as in other processors, arguments to functions are being passed directly to the floating point unit registers. While soft/softfp are forwards compatible, ie. a 'soft' app can run on a softfp system -but not vice versa- a 'hardfloat' application can run on neither of those systems. This means that in order to use hardfloat the system has to be completely rebuilt for hardfloat, down to the last application.

Why hardfloat?

It has been shown [1] that a typical application built with hardfloat is 5-40% faster than the softfp version. In cases of heavy floating point use, the speed increase can go even further -eg. povray was proven to be >200% faster! [2]

Why not?

Well, as noted above, it's incompatible with both soft and softfp. It's quite hard to build

Debian-armhf port

Initially, the first attempt at a hardfloat port was done using Ubuntu Karmic as shipped with the first Efikas. I rebuilt a complete gnome desktop and all of the package dependencies with -mfloat-abi=hard. Performance did show quite a big gain. This was the first step.

Next, in order to prove the point that a hardfloat-built port is worth the effort, an initiative was taken by Genesi USA -makers of EfikaMX smarttops/smartbooks- to build, maintain and support a new Debian port, debian-armhf. The base requirements for this port are: a) armv7-a, b) vfpv3-d16, c) thumb2. This means that all Cortex-A8/A9 cpus (incl. iMX515, OMAP3/4, Tegra2, etc), will be supported by this new port. Though NEON is not required at this point, it's possible there will be a new flavour of the armhf port with NEON in the future. The new port is now hosted in debian-ports.org (it started on freevec.org), until it reaches a more mature status, and it is for that reason that Genesi has also donated a 2x2TB disk set to the debian-ports initiative.

Genesi has provided me with 9 EfikaMX TO2 and 2 TO3 systems (6 of those form a buildd cluster for the armhf port, 1 TO2 is used for debian-installer tests, 1TO3 is used for Ubuntu Maverick tests , 1 TO3 for debian-armhf desktop use and tests and 2 are spare).

Current status?

The port now has ~80% of the main Debian archive built [3], in less than 2 months (buildds started officially to compile on Sep 10)! Though progress is fast, there have been some problems, both hardware and software related.

  1. iMX515 Tape Out 2 (TO2) suffers from ARM erratum #657417, which causes stalls or even complete system lockups. This erratum also affects several revisions chips such as the OMAP3530 as used on the Beagleboard. This has led a number of failed-attempted packages on buildd stats, which would otherwise build fine. This problem does not exist on more modern CPU revisions. It _may_ be possible to workaround this problem on the TO2 by patching ld to exclude certain code sequences that might cause lockups. There are several hundred or thousand EfikaMX (TO2) and Beagleboard systems out there (anything <C4) which could be employed in testing and development, therefore making this an important thing to fix.

  2. On the software side, we're still missing Java, Mono and some more language compilers (ghc6, fpc, clisp, etc). Some of those are also missing on armel.
  3. Initial debian-installer support. Most packages are built, except kernel images.
  4. Kernel armhf patches exist, but I have only EfikaMX systems to test d-i on, and EfikaMX kernels are 2.6.31.14 right now, a forward port/mainlining to 2.6.36 is in the process, but d-i needs 2.6.32+ right now.
  5. There are a significant number of packages with pending patches for armhf and more to follow. Most are trivial -missing arch keyword- but there are some that need non-trivial patches (qt4, gcc4.4, lintian, libmad, etc).

Problems with toolchain

Initially the first compiler used was the CodeSourcery 2009q3-67 compiler. This was necessary as FSF GCC pre-4.5 does not include the needed hardfloat support. Later, and as the Linaro project began to mature, a switch was made to the Linaro GCC, with a few extra patches (namely libtheora, hardfloat defines, etc). Just recently though, the Debian gcc-4.4.5 package included all relevant Linaro patches and this is being tested instead -the armhf-related patches are only a few lines long. The latest experimental Debian binutils (binutils-2.20.50-20100923) seem to include the ARM erratum fix as described above.

Triplet issues

The OS triplet is an important issue. Although a quad was initially decided to be used (arm-hardfloat-linux-gnueabi) which led to dpkg quads support to be added (Debian #594179), it was soon afterwards decided to be abandoned and keep the original triplet (arm-linux-gnueabi). However, an alternative to dpkg armhf support has not been proposed until now and so far, dpkg in armhf is patched with the quads support and seems to be working ok -more than 6.5k packages built with no problems, at least none related to dpkg. When dpkg properly supports armhf, with the original triplet, we expect to be able to do a complete rebuild of the packages, but with no bootstrapping needed.

Comparison with Debian armel and Ubuntu armel ports

Debian armel is armv5, -mfloat-abi=soft, whilst Ubuntu armel is armv7-a, vfpv3-d16, thumb2 and -mfloat-abi=softfp. Performance of armhf compared to Debian-armel is not really the issue here, as they have different base requirements and hence different targets. Debian armel might run on an EfikaMX, or on similar Cortex-A8/A9 devices, but it would be seriously unoptimized. However Ubuntu seems to have the same requirements with the exception of the float-abi being softfp vs hard. Those seem to hit pretty much the same target. So a comparison of debian-armhf vs ubuntu-armel would be more appropriate. However, as was noted, hard vs softfp performance was on average 35% in favour of hard, I believe Ubuntu devs would be at least interested in such a port.

Relevance of armel when armhf starts getting near completion

It should still be relevant at least where binary compatibility is important - Adobe Flash, some closed source codecs/drivers, etc. However once these also start to appear for armhf, I don't think it will be relevant for long.

Should there be an Ubuntu armhf port?

That's not my decision, but I think it would not be inappropriate to suggest an armhf port say for Natty or Natty+1.

Future: Next 6 months

  • Finish port along with proper d-i support (markos)
  • Proper mainlining EfikaMX kernel support (Genesi)
  • Adding an overlaid repository with a few NEON-enabled packages to be used with armhf
  • Other?

[1] http://www.powerdeveloper.org/forums/viewtopic.php?t=1821
[2] http://lists.debian.org/debian-arm/2010/07/msg00168.html
[3] http://wiki.debian.org/ArmHardFloatTodo

Linaro-arm-hardfloat (last modified 2010-11-12 06:57:40)