ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition

The System Level Programmers’ Model
B1.8.5 VFP support code
A complete VFP implementation might require a software component, known as the support code. For
example, if VFPv3U is implemented support code must handle the trapped floating-point exceptions.
Typically, the support code is entered through the ARM Undefined Instruction vector, when the extension
hardware does not respond to a VFP instruction. This software entry is known as a bounce.
When VFPv3U is implemented, the bounce mechanism is used to support trapped floating-point exceptions.
Trapped floating-point exceptions, known as traps, are floating-point exceptions that an implementation
passes back to application software to resolve, see Floating-point exceptions on page A2-42. The support
code must catch a trapped exception and convert it into a trap handler call.
The support code can perform other tasks, as determined by the implementation. It might be used for rare
conditions, such as operations that are difficult to implement in hardware, or operations that are gate
intensive in hardware. This permits consistent software behavior with varying degrees of hardware support.
The division of labor between the hardware and software components of an implementation, and details of
the interface between the support code and hardware are SUBARCHITECTURE DEFINED.
Asynchronous bounces, serialization, and VFP exception barriers
A VFP implementation can produce an asynchronous bounce, in which a VFP instruction takes the
Undefined Instruction exception because support code processing is required for an earlier VFP instruction.
The mechanism by which the nature of the required processing is communicated to the support code is
SUBARCHITECTURE DEFINED. Typically, it involves:
using the SUBARCHITECTURE DEFINED bits of the FPEXC, see The Floating-Point Exception Register
(FPEXC) on page B1-68
using the SUBARCHITECTURE DEFINED extension system registers, see Advanced SIMD and VFP
extension system registers on page B1-66
setting FPEXC.EX == 1, to indicate that the SUBARCHITECTURE DEFINED extension system registers
must be saved on a context switch.
An asynchronous bounce might not relate to the last VFP instruction executed before the one that took the
Undefined Instruction exception. It is possible that another VFP instruction has been issued and retired
before the asynchronous bounce occurs. This is possible only if this intervening instruction has no register
dependencies on the VFP instruction that requires support code processing. In addition. it is possible that
there are SUBARCHITECTURE DEFINED mechanisms for handling an intervening VFP instruction that has
issued but not retired.
However, VMRS and VMSR instructions that access the FPSID, FPSCR, or FPEXC registers are serializing
instructions. This means they ensure that any exceptional condition in any preceding VFP instruction that
requires support code processing has been detected and reflected in the extension system registers before
they perform the register transfer. A VMSR instruction to the read-only FPSID register is a serializing NOP.
B1-70 Copyright © 1996-1998, 2000, 2004-2008 ARM Limited. All rights reserved. ARM DDI 0406B