ARM Linux, at least Debian was traditionally (pre eabi) built for the FPA floating point unit*. Unfortunately under old ABI it was not easily possible to mix soft-float code with FPA code. The result of this is that many arm Linux systems ended up relying on kernel emulation of floating point, and this was a large part of the impetus for the eabi port.

What is puzzling me is how we got to this situation in the first place. It seems that few arm systems had it. It seems it was an optional extra for the Acorn A540 and Acorn A5000 and it was promised for the Acorn Risc PC, but I can't find any evidence it made it past the prototype stage, and the Risc PC was already about 5 years old by the time Debian was released for ARM.

Is there any history available on why this decision was made? Is there any other significant arm hardware with FPA that I have missed?

* Not to be confused with the VFP floating point units arm use today.

  • What is an FPA and how is it wired up? And what's it relation with a PowerPC based Amiga 5000?
    – Raffzahn
    Jan 19, 2020 at 15:45
  • 1
    Acorn A5000, not amiga A5000. Jan 19, 2020 at 15:55
  • 4
    FPA is a floating point unit, connected to the ARM's coproessor interface, the systems I am aware of with FPA had it as a seperate chip, but I can't rule out it existing as a larger chip. chrisacorns.computinghistory.org.uk/docs/GECPlessey/… Jan 19, 2020 at 16:06
  • 4
    Peter, you might want to add this link plu some words to the question so interested readers get an idea what it's about. It's a great idea to help non-initiate along.
    – Raffzahn
    Jan 19, 2020 at 16:11
  • 1
    There was indeed a computer I had missed, the Acorn A7000+ had FPA support using the ARM7500FE mentioned in Igors answer. Jan 21, 2020 at 1:57

2 Answers 2


It seems FPA itself was pretty short lived. From the ARM Linux mailing list (2004):

There were only few devices which contained the FPA (ARM7500FE which is a complete system-on-chip, and FPA11 as external coprocessor to ARM3 if I remember correctly). Despite still being widely used, this instruction set is not documented in the ARM ARM. The only source for documentation about it that I know is the ARM7500FE data sheet.

The only other FPA implementation I am aware of was MaverickCrunch by Cirrus Logic (2000). Although seemingly not too successful by itself, it did introduce the FPA support into GCC and so FPA remained a commonly accepted interface for floating-point code until introduction of VFP by ARM (apparently with VFP9-S in 2002). Switching over to EABI took several years and FPA support was finally removed from GCC in 2012.

P.S. for compatibility, the ARM register layout used by GDB still reserves space for the FPA registers between PC and CPSR.

EDIT: this 1999 writeup by Scott Bambrough from NetWinder project has more background on FPA in Acorn, StrongARM, NetBSD and Linux.

  1. The NetWinder Floating Point Hardware

There is none. The StrongARM unlike the Intel x86 series of CPU's has no integrated floating point hardware. ARM manufactures a coprocessor floating point unit; the FPA11, however it is only available on the ARM 7500FE and it is not compatible with the Intel StrongARM chips. Hence the Netwinder has no floating point hardware at all. It depends entirely on software that emulates the FPA11 floating point unit.

So how do various systems deal with the lack of floating point hardware? Acorn developed their own emulator from scratch for their RISC operating systems. The ARM port of NetBSD has a unique solution; the binary object code for the ARM floating pointing routines was converted into a text file of hexidecimal numbers. Some assembler glue is added to the file and the assembler is then used to convert the file back to binary form. Hence the NetBSD kernel, contains source of a sort, although it is unreadable and not maintainable. Russell King distributes a port of the Acorn floating point emulator that is compatible with ARM Linux kernels.

There are actually two floating point emulators available for ARM Linux. A version of the Acorn emulator was ported to ARM Linux by Russell King. He has a very specific licence which allows him to distribute this emulator as a module with most of the symbols stripped out from his web site. It is well established, in its third release. It is highly optimized, and written in ARM assembly language.

The licence restrictions on the Acorn FPE proved problematic for the NetWinder. It looked like it would be expensive to licence the emulator from Acorn.


As luck would have it Phil Blundell had brought to my attention a free library of code implementing IEEE floating point algorithms. SoftFloat is a complete IEEE 754 floating point library written by John Hauser. Neil Carson had ported this software to run on the ARM platform, and Phil had modified it to create a library for use with the compiler when the -msoft-float compiler flag was used. With SoftFloat in hand, it was possible to concentrate on building just the emulation code for the floating point hardware. Thus the NWFPE was born.

NWFPE was adopted by ARM Linux and the code is still there. I imagine it can still be used if you enable OABI support (e.g. if you need to support ARMv4 without Thumb).

Additional reading: ARM Application Note 98: VFP Support Code.

  • 1
    You just found a crucial lead in this saga! Googling ARM7500FE took me to the wikipedia page for the A7000 series, so it seems while RiscPCs with FPA most likely never made it to market an A7000 variant with it did. Jan 21, 2020 at 1:14
  • 2
    And your update basically confirms this was a case of the Linux guys following Acorn practices (and then later writing their own emulator when the license terms of Acorn's one proved problematic). Jan 22, 2020 at 4:49
  • 1
    If anyone here has enough rep for a 2-character edit, there is now an https version of the infradead.org URL, and also of the URL for Scott Bambrough's writeup. Also, many thanks to Igor for this very interesting and informative answer!
    – AJM
    Jul 28, 2022 at 12:00

My experience with ARM Linux was that it was typically used for embedded systems which were not expected to routinely carry an FPU of any kind, with the notable exceptions of Android phones and the Raspberry Pi.

Even the initial builds of Raspbian used a softfloat build, which made no attempt to use the VFP. I was actually involved in building a hardfloat image of Gentoo for the machine so that comparative benchmarks could be run, which led to the hardfloat build of Raspbian becoming standard. This was already well into the EABI era.

I fear your recollection may actually be backwards. FPA code could be run via a kernel-supported software emulator known as FPE, and would merely take invalid-instruction traps to do so. Acorn used this technique for their own BBC BASIC VI, which introduced 64-bit IEEE floating point, in contrast to earlier versions which used a proprietary 40-bit format which could not be hardware accelerated at all.

This was not a very efficient mechanism, but a number of official FPA instructions were executed this way as the FPA hardware didn't directly support them. FPA code could pass FP values in FPU registers even without FPU hardware physically fitted; they would then be in emulated registers.

It seems likely that early ARM Linux ports merely replicated this practice, with the absence of FPA hardware for Linux-compatible CPUs only being noticed later.

No such emulator, however, was provided for running VFP code on an FPU-less machine. Softfloat code did not contain any FPU instructions, and would keep FP values in integer registers for parameter passing. Hardfloat code passes FP values in FPU registers. Hence under EABI, softfloat and hardfloat code cannot be mixed (without a shim layer to translate ABIs, which is rarely implemented).

  • 1
    Peter is referring to the OABI version of Debian, arm, which did build for FPA (see the legacy flags on the EABI port page on the Debian wiki). Jan 19, 2020 at 19:44
  • @StephenKitt Yes, exactly. I suspect the original port followed Acorn's practice (exemplified in BBC BASIC VI) of coding for FPA, not considering the lack of physical FPA coprocessors for ARMv3 and later CPUs, and thus relying on the FPE in practice.
    – Chromatix
    Jan 19, 2020 at 19:52
  • 1
    Ah, right, thanks — that goes a long way towards explaining the “why”! May I suggest adding that this was Acorn’s practice in your answer? Jan 19, 2020 at 20:05
  • I have a few comments on this answer firstly the initial builds for the raspberry pi were Debian armel, Raspbian was created specifically to address providing a hardfloat port for the raspberry pi. Secondly I don't recall any involvement of gentoo in either the descision to create Raspbian in the first place or the descision for the Raspbery pi foundation to adopt it as their primary OS. Jan 20, 2020 at 0:39
  • Secondly gcc does have a mode "-mfloat-abi=softfp" where it uses the FPU, but uses the soft-float ABI. I think ubuntu used said mode for a while, though it never really took off widely. Jan 20, 2020 at 0:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .