VFP Execution Environment (Rev #8, changes)

Goals

There is currently a bias towards using the older FPA instruction set for floating point operations ostensiby because the majority of RISC OS systems were based around the ARM7500FE or lacked floating point hardware entirely – and in that situation a floating point emulator was a good way to have code be able to run in either scenario.

Since ARM11 the scales have tipped the other way as these cores implement one variant or another of the VFP hardware macrocell, Arm’s replacement for the FPA. Ignoring VFPv1, since RISC OS never ran on any of the chips and version 1 has since been obsoleted, this means VFPv2 or VFPv3 or VFPv4.

This proposal looks at how to better integrate hardware floating point support within RISC OS, primarily for those clients of the Shared C Library, but also setting out examples by which hardware floating point support can be detected so that when multiple variants are supplied the correct one is run.

Existing documentation

Relevant specifications

IHI0042 – Procedure Call Standard for the Arm 32-bit Architecture
DUI0041 – ARM Object Format (AOF)

Relevant forum threads

VFP implementations of transcendental functions and decimal conversion
BASICVFP
Taking FP seriously
FP support
VFP context switching

Terminology

FPA is the original Floating Point Accelerator, coprocessor numbers 1 & 2 for the ARM.
VFP is the Vector Floating Point unit, coprocessor numbers 10 & 11 for the ARM.
The APCS is the ARM Procedure Calling Standard, treated as a synonym here for ATPCS (for ARM/Thumb PCS), and AAPCS (for ARM Architecture PCS).
An ABI defines an Application Binary Interface, comprising a base ABI for the core-registers only and basis for several variants.

Detail

APCS amendments

The Shared C Library

Client registration

Code which was built to use VFP, and thus follows the new APCS-VFP, will need to call a new library initialisation SWI during startup. One SWI for application clients and one for module clients (cf. SharedCLibrary_LibInitAPCS_32 and SharedCLibrary_LibInitModuleAPCS_32). If the SharedCLibrary is too old the unknown SWI error returned will prevent the application or module from starting.

The C library runtime will create a VFP context, since there isn’t a global context as for FPA, and destroy it on library close down if the application or module quits along with file handles and the other usual exit clear up.

Code which is not a client of the Shared C Library

Code which doesn’t use the Shared C Library is responsible for managing its own context. For example BASIC compiled using the ABC compiler uses its own ABCLibrary support module and uses VFPSupport directly to manage contexts.

Functions affected

A number of the C functions from $are\; currently\; implemented\; in\; assembler\; which\; uses$FPA opcodes, and some are directly inlined by the compiler as FPA opcodes. The bulk of the functions are in cl_body.s cxsupport.s fenv.s and mathasm.s, plus a couple of lines in longlong.s and k_body.s.

For ease of maintenance moving the floating point library code out of cl_body.s would be worthwhile. They will each need an equivalent implementation in VFP, or some of the more obscure functions could be veneered by swapping the word order from VFP to FPA and calling the existing proven code.

Variadic functions such as printf() receive all their arguments in integer registers. This causes an issue for floating point values which are always widened to doubles, since doubles for an FPA client have the word order reversed compared with VFP. By the time the variadic function is called the type information which was to hand at the compiling stage has been lost so this will either require two copies of the variadic functions, or some abstraction at the point va_arg() is used to retrieve a double.

Exceptions

Some later variants of the VFP macrocell don’t raise an abort for invalid operations such as the square root of a negative number. The compiler may opt to insert checks of the FPSCR after certain operations or on return from a function for example in order to prevent invalid results from silently being propagated. This will need support functions in the Shared C Library to report them to the signal handler in the C environment, so that they may be handled in a controlled manner.

Toolchain switches

ROM based components

CC -apcs 3/32bit/fpregargs/vfp -cpu 7 -fpu VFPv4 -memaccess +L22+S22-L41
ObjAsm -apcs 3/32bit/fpregargs/vfp -cpu 7 --fpu VFPv4

CC -apcs 3/32bit/fpregargs/vfp -arch 3 -fpu VFPv2 -memaccess -L22-S22-L41
ObjAsm -apcs 3/32bit/fpregargs/vfp -arch 3 --fpu VFPv2

VFP Emulator

NEON and the NeVer condition code

Why not retrofit FPEmulator?

Selecting a !RunImage

Implementation progress

Document history

v1.00 – 26-Dec-2021

• Outline added