History of ARM Linux and FPA

Question

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.

Answer 1

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.

Answer 2

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).