| |||
| Home > Handling Processor Exceptions > 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:
Attach itself to the Undefined Instruction vector and store the old contents.
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.
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.
The Thumb instruction set does not have coprocessor instructions, so there should be no need for the Undefined Instruction handler to emulate such instructions.