You copied the Doc URL to your clipboard.

Undefined instruction handlers

In some cases, an undefined instruction exception can be handled by a software emulator for a coprocessor.

An undefined instruction exception is generated in the following cases:

  • if the processor does not recognize an instruction

  • if the processor recognizes an instruction as a coprocessor instruction, but no coprocessor recognizes it.

It might be that the instruction is intended for a coprocessor, but the relevant coprocessor, for example VFP, is not attached to the system, or is disabled. However, a software emulator for such a coprocessor might be available.

Such an emulator must:

  1. Attach itself to the undefined instruction vector and store the old contents.

  2. Examine the undefined instruction to see if it has to be emulated. This is similar to the way in which an SVC handler extracts the number of an SVC, but rather than extracting the bottom 24 bits, the emulator must extract bits [27:24].

    These bits determine whether the instruction is a coprocessor operation in the following way:

    • If bits [27:24] = b1110 or b110x, the instruction is a coprocessor instruction.

    • If bits [8:11] show that this coprocessor emulator has to handle the instruction, the emulator must process the instruction and return to the user program.

  3. Otherwise the emulator must pass the exception onto the original handler, or the next emulator in the chain, using the vector stored when the emulator was installed.

When a chain of emulators is exhausted, the undefined instruction handler must report an error and quit.


The pre-ARMv6T2 Thumb instruction set does not have coprocessor instructions, so there is no requirement for the undefined instruction handler to emulate such instructions.