Comtrol eCos - Manual (Page 303)

Chapter 10. Exception Handling
Vectors and VSRs
The CPU delivers all exceptions, whether synchronous faults or asynchronous interrupts, to a set of hardware
defined vectors. Depending on the architecture, these may be implemented in a number of different ways. Examples
of existing mechanisms are:
PowerPC
Exceptions are vectored to locations 256 bytes apart starting at either zero or 0xFFF00000 . There are 16 such
vectors defined by the basic architecture and extra vectors may be defined by specific variants. One of the base
vectors is for all external interrupts, and another is for the architecture defined timer.
MIPS
Most exceptions and all interrupts are vectored to a single address at either 0x80000000 or 0xBFC00180 .
Software is responsible for reading the exception code from the CPU cause register to discover its true
source. Some TLB and debug exceptions are delivered to different vector addresses, but these are not used
currently by eCos. One of the exception codes in the
cause register indicates an external interrupt. Additional
bits in the cause register provide a first-level decode for the interrupt source, one of which represents an
architecture defined timer.
IA32
Exceptions are delivered via an Interrupt Descriptor Table (IDT) which is essentially an indirection table
indexed by exception number. The IDT may be placed anywhere in memory. In PC hardware the standard
interrupt controller can be programmed to deliver the external interrupts to a block of 16 vectors at any offset
in the IDT. There is no hardware supplied mechanism for determining the vector taken, other than from the
address jumped to.
ARM
All exceptions, including the FIQ and IRQ interrupts, are vectored to locations four bytes apart starting at
zero. There is only room for one instruction here, which must immediately jump out to handling code higher
in memory. Interrupt sources have to be decoded entirely from the interrupt controller.
With such a wide variety of hardware approaches, it is not possible to provide a generic mechanism for the substi-
tution of exception vectors directly. Therefore, eCos translates all of these mechanisms in to a common approach
that can be used by portable code on all platforms.
The mechanism implemented is to attach to each hardware vector a short piece of trampoline code that makes an
indirect jump via a table to the actual handler for the exception. This handler is called the Vector Service Routine
(VSR) and the table is called the VSR table.
The trampoline code performs the absolute minimum processing necessary to identify the exception source, and
jump to the VSR. The VSR is then responsible for saving the CPU state and taking the necessary actions to handle
the exception or interrupt. The entry conditions for the VSR are as close to the raw hardware exception entry state
as possible - although on some platforms the trampoline will have had to move or reorganize some registers to do
its job.
To make this more concrete, consider how the trampoline code operates in each of the architectures described
above:
199