1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Vectors and VSRs</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="Exception Handling"
23 HREF="hal-exception-handling.html"><LINK
25 TITLE="Exception Handling"
26 HREF="hal-exception-handling.html"><LINK
28 TITLE="Default Synchronous Exception Handling"
29 HREF="hal-default-synchronous-exception-handling.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="hal-exception-handling.html"
65 >Chapter 10. Exception Handling</TD
71 HREF="hal-default-synchronous-exception-handling.html"
85 NAME="HAL-VECTORS-AND-VSRS">Vectors and VSRs</H1
87 >The CPU delivers all exceptions, whether
88 synchronous faults or asynchronous interrupts, to a set of hardware
89 defined vectors. Depending on the architecture, these may be
90 implemented in a number of different ways. Examples of existing
101 > Exceptions are vectored to locations 256 bytes apart starting at
106 vectors defined by the basic architecture and extra vectors may
107 be defined by specific variants. One of the base vectors is for
108 all external interrupts, and another is for the architecture
116 > Most exceptions and all interrupts are vectored to a single
117 address at either <TT
124 >. Software is responsible for
125 reading the exception code from the CPU <TT
129 register to discover its true source. Some TLB and debug
130 exceptions are delivered to different vector addresses, but
131 these are not used currently by eCos. One of the exception codes
135 > register indicates an external
136 interrupt. Additional bits in the <TT
140 register provide a first-level decode for the interrupt source,
141 one of which represents an architecture defined timer.
148 > Exceptions are delivered via an Interrupt Descriptor Table (IDT)
149 which is essentially an indirection table indexed by exception
150 number. The IDT may be placed anywhere in memory. In PC hardware
151 the standard interrupt controller can be programmed to deliver
152 the external interrupts to a block of 16 vectors at any offset
153 in the IDT. There is no hardware supplied mechanism for
154 determining the vector taken, other than from the address jumped
162 > All exceptions, including the FIQ and IRQ interrupts, are
163 vectored to locations four bytes apart starting at zero. There
164 is only room for one instruction here, which must immediately
165 jump out to handling code higher in memory. Interrupt sources
166 have to be decoded entirely from the interrupt controller.
172 >With such a wide variety of hardware approaches, it is not possible to
173 provide a generic mechanism for the substitution of exception vectors
174 directly. Therefore, eCos translates all of these mechanisms in to a
175 common approach that can be used by portable code on all platforms.</P
177 >The mechanism implemented is to attach to each hardware vector a short
178 piece of trampoline code that makes an indirect jump via a table to
179 the actual handler for the exception. This handler is called the
180 Vector Service Routine (VSR) and the table is called the VSR table.</P
182 >The trampoline code performs the absolute minimum processing necessary
183 to identify the exception source, and jump to the VSR. The VSR is then
184 responsible for saving the CPU state and taking the necessary actions
185 to handle the exception or interrupt. The entry conditions for the VSR
186 are as close to the raw hardware exception entry state as possible -
187 although on some platforms the trampoline will have had to move or
188 reorganize some registers to do its job.</P
190 >To make this more concrete, consider how the trampoline code operates
191 in each of the architectures described above:</P
201 > A separate trampoline is contained in each of the vector
202 locations. This code saves a few work registers away to the
203 special purposes registers available, loads the exception number
204 into a register and then uses that to index the VSR table and
205 jump to the VSR. The VSR is entered with some registers move to
206 the SPRs, and one of the data register containing the number of
214 > A single trampoline routine attached to the common vector reads
215 the exception code out of the <TT
219 and uses that value to index the VSR table and jump to the VSR.
220 The trampoline uses the two registers defined in the ABI for
221 kernel use to do this, one of these will contain the exception
222 vector number for the VSR.
229 > There is a separate 3 or 4 instruction trampoline pointed to by
230 each active IDT table entry. The trampoline for exceptions that
231 also have an error code pop it from the stack and put it into a
232 memory location. Trampolines for non-error-code exceptions just
233 zero the memory location. Then all trampolines push an
234 interrupt/exception number onto the stack, and take an indirect
235 jump through a precalculated offset in the VSR table. This is
236 all done without saving any registers, using memory-only
237 operations. The VSR is entered with the vector number pushed
238 onto the stack on top of the standard hardware saved state.
245 > The trampoline consists solely of the single instruction at the
246 exception entry point. This is an indirect jump via a location
247 32 bytes higher in memory. These locations, from
251 > up, form the VSR table. Since each VSR
252 is entered in a different CPU mode
255 >SVC,UNDEF,ABORT,IRQ or FIQ</TT
257 different VSR for each exception that knows how to save the CPU
269 SUMMARY="Footer navigation table"
280 HREF="hal-exception-handling.html"
298 HREF="hal-default-synchronous-exception-handling.html"
308 >Exception Handling</TD
314 HREF="hal-exception-handling.html"
322 >Default Synchronous Exception Handling</TD