User guide

5.7 Undefined Instruction handlers

Instructions that are not recognized by the processor are offered to any coprocessors attached to the system. If the

instruction remains unrecognized, an Undefined Instruction exception is generated. It could be the case that the

instruction is intended for a coprocessor, but that the relevant coprocessor, for example a Floating Point Accelerator,

is not attached to the system. 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 should be emulated. This is similar to the way in which a SWI

handler extracts the number of a SWI, 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 to 24 = b1110 or b110x, the instruction is a coprocessor instruction.

• If bits 8-11 show that this coprocessor emulator should 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, no further processing of the instruction can take place, so the Undefined

Instruction handler should report an error and quit. See Chaining exception handlers for more information.

Note

The Thumb instruction set does not have coprocessor instructions, so there should be no need for the Undefined

Instruction handler to emulate such instructions.

Handling Processor Exceptions