La importancia de las palabras

As we have already seen, the A classes and R classes of architecture support seven processor modes, six privileged modes called FIQ, IRQ, SUPERVISOR, ABORT, UNDEFINED and SYSTEM, and the non-privileged USER mode. The HYP mode and MONITOR registers can be added to the list where the Virtualization and Security Extensions are implemented.The current mode can change under software control or when processing an exception.

However, the unprivileged User mode can switch to another mode only by generating an exception.

An exception is any condition that needs to halt normal execution and instead run software associated with each exception type, known as an exception handler.

When an exception occurs, the processor saves the current status and the return address, enters a specific mode and possibly disables hardware interrupts. Execution is then forced from a fixed memory address called an exception vector. This happens automatically and is not under direct control of the programmer.

The following types of exception exist:

Interrupts There are two types of interrupts provided on ARMv7-A processors, called IRQ and FIQ.

FIQ is higher priority than IRQ. FIQ also has some potential speed advantages owing to its position in the vector table and the higher number of banked registers available in FIQ mode. This potentially saves processor clock cycles on pushing registers to the stack within the handler. Both of these kinds of exception are typically associated with input pins on the processor – external hardware asserts an interrupt request line and the corresponding exception type is raised when the current instruction finishes executing, assuming that the interrupt is not disabled. Aborts Aborts can be generated either on instruction fetches (prefetch aborts) or data

accesses (data aborts). They can come from the external memory system giving an error response on a memory access (indicating perhaps that the specified address does not correspond to real memory in the system). Alternatively, the abort can be generated by the Memory Management Unit (MMU) of the processor. An operating system can use MMU aborts to dynamically allocate memory to applications. An instruction can be marked within the pipeline as aborted, when it is fetched. The prefetch abort exception is taken only if the processor then actually tries to execute it. The exception takes place before the instruction actually executes. If the pipeline is flushed before the aborted instruction reaches the execute stage of the pipeline, the abort exception will not occur. A data abort exception happens when a load or store instruction executes and is considered to happen after the data read or write has been attempted. The ARMv7 architecture distinguishes between precise and imprecise aborts. Aborts generated by the MMU are always precise. The architecture does not require particular classes of externally aborted accesses to be precise.

For example, on a particular processor implementation, it may be the case that an external abort reported on a page table walk is treated as precise, but this is not required to be the case for all processors. For precise aborts, the abort handler can be certain which instruction caused the abort and that no further instructions were executed after that instruction. This is in contrast to an imprecise abort, which results when the external memory system reports an error on an access. In this case, the abort handler cannot determine which instruction caused the problem (or further instructions may have executed after the one which generated the abort). For example, if a buffered write receives an error response from the external memory system, further instructions will have been executed after the store. This

Exception Handling

means that it will be impossible for the abort handler to fix the problem and return to the application. All it can do is to kill the application which caused the problem. Device probing therefore needs special handling, as externally reported aborts on reads to non-existent areas will generate imprecise, asynchronous aborts even when such memory is marked as Strongly-ordered, or Device. Generation of imprecise aborts is controlled by the CPSR A bit. If the A bit is set, imprecise aborts from the external memory system will be recognized by the processor, but no abort exception will be generated immediately. Instead, the processor keeps the abort pending until the A bit is cleared and takes an exception at that time. This bit is set by default on reset, and certain other exception types. Kernel code will typically ensure (through the use of a barrier instruction) that pending imprecise aborts are recognized against the correct application. If a thread has to be killed due to an imprecise abort, it needs to be the correct one!

Reset All processors have a reset input and will take the reset exception immediately after they have been reset. It is the highest priority exception and cannot be masked.

Exceptional instructions

There are two classes of instruction which can cause exceptions on the ARM. The first is the Supervisor Call (SVC), previously known as Software Interrupt (SWI).

This is typically used to provide a mechanism by which User mode programs can pass control to privileged, kernel code in the OS to perform OS-level tasks. The second is an undefined instruction. The architecture defines certain bit-patterns as corresponding to undefined opcodes. Trying to execute one of these causes an Undefined Instruction exception to be taken. In addition, executing coprocessor instructions for which there is no corresponding coprocessor hardware will also cause this trap to happen. Some instructions can be executed only in a privileged mode and executing these from User mode will cause an undefined instruction exception.

When an exception occurs, code execution passes to an area of memory called the vector table. Within the table just one word is allocated to each of the various exception types and this will usually contain a branch instruction to the actual exception handler.

You can write the exception handlers in either ARM or Thumb code. The CP15 SCTLR.TE bit is used to specify whether exception handlers will use ARM or Thumb. When handling exceptions, the prior mode, state, and registers of the processor must be preserved so that the program can be resumed after the exception has been handled.