Differences between revisions 1 and 2
Revision 1 as of 2010-07-08 13:57:14
Size: 1557
Editor: ?LoicMinier
Comment:
Revision 2 as of 2010-07-08 14:06:09
Size: 2317
Editor: ?LoicMinier
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
== Background information on ARM EABI, GCC floating-point ABIs, hwcaps == == Background information ==

This section provides some background information on FPUs, ARM EABI, GCC floating-point ABIs, hwcaps...

=== VFP ===

ARM vendors used to ship their System-on-Chip (SoC) designs with different FPUs; the instruction set of the CPU would be the same on all ARMv4 chips, but the FPU implementation would differ, with different FPU instruction sets.

ARM standardized a particular FPU instruction set under the name Vector Floating Point (VFP); this is now effectively the norm in ARMv6 SoCs with a FPU and later.

VFP was extended over time, with VFPv3 introduced with ARMv7. Some ARMv7 chips such as Marvell Dove or NVidia Tegra do have a VFP FPU, but with limited floating-point precision, so not fully VFPv3 compatible. This variant is selected in gcc with `-mfpu=vfpv3-d16`.
Line 15: Line 25:
GCC when targeting ARM EABI supports three floating-point ABIs with -mfloat-abi=:
 * soft: never use the FPU, pass floating-point values on the stack, emulate floating-point operations
 * hard: always use the FPU, pass floating-point values in FPU registers
 * softfp: pass floating-point values on the stack across function calls, but allow the use of the FPU within a function
GCC when targeting ARM EABI supports three floating-point ABIs with `-mfloat-abi=`:
 * `soft`: never use the FPU, pass floating-point values on the stack, emulate floating-point operations
 * `hard`: always use the FPU, pass floating-point values in FPU registers
 * `softfp`: pass floating-point values on the stack across function calls, but allow the use of the FPU within a function
Line 20: Line 30:
Calling functions built with softfp requires the presence of a FPU, but it's possible to only call softfp variants of functions at runtime. It is also possible to have two sets of libraries, a set built with softfp and a set built with soft floating-point ABI, and the eglibc runtime loader will select the right one depending on the presence of a FPU on the running system, this is called hwcaps. Calling functions built with `softfp` requires the presence of a FPU, but it's possible to only call `softfp` variants of functions at runtime. It is also possible to have two sets of libraries, a set built with `softfp` and a set built with `soft` floating-point ABI, and the eglibc runtime loader will select the right one depending on the presence of a FPU on the running system, this is called hwcaps.

This page gathers thoughts and ideas around a hard-float ARM port for Debian.

Rationale

A lot of modern ARM boards and devices ship with a floating-point unit (FPU), but the current Debian armel port doesn't take much advantage of it.

A new ARM port requiring the presence of a FPU would help squeeze the most performance juice out of hardware with a FPU.

Background information

This section provides some background information on FPUs, ARM EABI, GCC floating-point ABIs, hwcaps...

VFP

ARM vendors used to ship their System-on-Chip (SoC) designs with different FPUs; the instruction set of the CPU would be the same on all ARMv4 chips, but the FPU implementation would differ, with different FPU instruction sets.

ARM standardized a particular FPU instruction set under the name Vector Floating Point (VFP); this is now effectively the norm in ARMv6 ?SoCs with a FPU and later.

VFP was extended over time, with VFPv3 introduced with ARMv7. Some ARMv7 chips such as Marvell Dove or NVidia Tegra do have a VFP FPU, but with limited floating-point precision, so not fully VFPv3 compatible. This variant is selected in gcc with -mfpu=vfpv3-d16.

The ARM EABI specification covers calling conventions across libraries and binaries, for instance it explains whether to pass floating-point values in registers or on the stack across library calls.

It supports both using FPU registers to pass values and usage of the stack, which is needed when there isn't a FPU.

GCC when targeting ARM EABI supports three floating-point ABIs with -mfloat-abi=:

  • soft: never use the FPU, pass floating-point values on the stack, emulate floating-point operations

  • hard: always use the FPU, pass floating-point values in FPU registers

  • softfp: pass floating-point values on the stack across function calls, but allow the use of the FPU within a function

Calling functions built with softfp requires the presence of a FPU, but it's possible to only call softfp variants of functions at runtime. It is also possible to have two sets of libraries, a set built with softfp and a set built with soft floating-point ABI, and the eglibc runtime loader will select the right one depending on the presence of a FPU on the running system, this is called hwcaps.