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

In addition:
The System Level Programmers’ Model
A VMRS or VMSR instruction that accesses the FPSCR acts as a VFP exception barrier. This means it
ensures that any outstanding exceptional conditions in preceding VFP instructions have been detected
and processed by the support code before it performs the register transfer. If necessary, the VMRS or
VMSR instruction takes an asynchronous bounce to force the processing of outstanding exceptional
conditions.
VMRS and VMSR instructions that access the FPSID or FPEXC do not take asynchronous bounces.
VFP serialization and the VFP exception barriers are described in pseudocode by the SerializeVFP() and
VFPExcBarrier() functions respectively:
SerializeVFP()
VFPExcBarrier()
Interactions with the ARM architecture
ARM recommends that a VFP extension uses the Undefined Instruction mechanism to invoke its support
code, see Undefined Instruction exceptions on page B1-76. To do this:
1. Before enabling the extension hardware, install the support code on the Undefined Instruction vector.
2. If the extension hardware requires assistance from the support code, it does not respond to a VFP
instruction.
3. This causes an Undefined Instruction exception, that causes the support code to be executed.
VFP load/store instructions can generate Data Abort exceptions, and therefore implementations must be
able to cope with a Data Abort exception on any memory access caused by such instructions.
Interrupts
Taking the Undefined Instruction exception causes IRQs to be disabled, see Undefined Instruction exception
on page B1-49. Normally, IRQs are not re-enabled until the exception handler returns. This means that
normal use of a VFP extension that requires support code in a system can increases worst case IRQ latency
considerably.
You can reduce this IRQ latency penalty considerably by explicitly re-enabling interrupts soon after entry
to the Undefined Instruction handler. This requires careful integration of the Undefined Instruction handler
into the rest of the operating system. How this might be done is highly system-specific and beyond the scope
of this manual.
A system where the IRQ handler itself might use the VFP coprocessor has a second potential cause of
increased IRQ latency. This increase occurs if a long latency VFP operation is initiated by the interrupted
application program, denying the use of the extension hardware to the IRQ handler for a significant number
of cycles.
ARM DDI 0406B Copyright © 1996-1998, 2000, 2004-2008 ARM Limited. All rights reserved. B1-71