OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [hal-vectors-and-vsrs.html] - Blame information for rev 588

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 28 unneback
<!-- 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.               -->
9
<HTML
10
><HEAD
11
><TITLE
12
>Vectors and VSRs</TITLE
13
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14
<META
15
NAME="GENERATOR"
16
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17
"><LINK
18
REL="HOME"
19
TITLE="eCos Reference Manual"
20
HREF="ecos-ref.html"><LINK
21
REL="UP"
22
TITLE="Exception Handling"
23
HREF="hal-exception-handling.html"><LINK
24
REL="PREVIOUS"
25
TITLE="Exception Handling"
26
HREF="hal-exception-handling.html"><LINK
27
REL="NEXT"
28
TITLE="Default Synchronous Exception Handling"
29
HREF="hal-default-synchronous-exception-handling.html"></HEAD
30
><BODY
31
CLASS="SECTION"
32
BGCOLOR="#FFFFFF"
33
TEXT="#000000"
34
LINK="#0000FF"
35
VLINK="#840084"
36
ALINK="#0000FF"
37
><DIV
38
CLASS="NAVHEADER"
39
><TABLE
40
SUMMARY="Header navigation table"
41
WIDTH="100%"
42
BORDER="0"
43
CELLPADDING="0"
44
CELLSPACING="0"
45
><TR
46
><TH
47
COLSPAN="3"
48
ALIGN="center"
49
>eCos Reference Manual</TH
50
></TR
51
><TR
52
><TD
53
WIDTH="10%"
54
ALIGN="left"
55
VALIGN="bottom"
56
><A
57
HREF="hal-exception-handling.html"
58
ACCESSKEY="P"
59
>Prev</A
60
></TD
61
><TD
62
WIDTH="80%"
63
ALIGN="center"
64
VALIGN="bottom"
65
>Chapter 10. Exception Handling</TD
66
><TD
67
WIDTH="10%"
68
ALIGN="right"
69
VALIGN="bottom"
70
><A
71
HREF="hal-default-synchronous-exception-handling.html"
72
ACCESSKEY="N"
73
>Next</A
74
></TD
75
></TR
76
></TABLE
77
><HR
78
ALIGN="LEFT"
79
WIDTH="100%"></DIV
80
><DIV
81
CLASS="SECTION"
82
><H1
83
CLASS="SECTION"
84
><A
85
NAME="HAL-VECTORS-AND-VSRS">Vectors and VSRs</H1
86
><P
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
91
mechanisms are:</P
92
><P
93
></P
94
><DIV
95
CLASS="VARIABLELIST"
96
><DL
97
><DT
98
>PowerPC</DT
99
><DD
100
><P
101
>      Exceptions are vectored to locations 256 bytes apart starting at
102
      either zero or <TT
103
CLASS="LITERAL"
104
>0xFFF00000</TT
105
>. There are 16 such
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
109
      defined timer.
110
      </P
111
></DD
112
><DT
113
>MIPS</DT
114
><DD
115
><P
116
>      Most exceptions and all interrupts are vectored to a single
117
      address at either <TT
118
CLASS="LITERAL"
119
>0x80000000</TT
120
> or
121
      <TT
122
CLASS="LITERAL"
123
>0xBFC00180</TT
124
>. Software is responsible for
125
      reading the exception code from the CPU <TT
126
CLASS="LITERAL"
127
>cause</TT
128
>
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
132
      in the <TT
133
CLASS="LITERAL"
134
>cause</TT
135
> register indicates an external
136
      interrupt. Additional bits in the <TT
137
CLASS="LITERAL"
138
>cause</TT
139
>
140
      register provide a first-level decode for the interrupt source,
141
      one of which represents an architecture defined timer.
142
      </P
143
></DD
144
><DT
145
>IA32</DT
146
><DD
147
><P
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
155
      to.
156
      </P
157
></DD
158
><DT
159
>ARM</DT
160
><DD
161
><P
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.
167
      </P
168
></DD
169
></DL
170
></DIV
171
><P
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
176
><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
181
><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
189
><P
190
>To make this more concrete, consider how the trampoline code operates
191
in each of the architectures described above:</P
192
><P
193
></P
194
><DIV
195
CLASS="VARIABLELIST"
196
><DL
197
><DT
198
>PowerPC</DT
199
><DD
200
><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
207
      the vector taken.
208
      </P
209
></DD
210
><DT
211
>MIPS</DT
212
><DD
213
><P
214
>      A single trampoline routine attached to the common vector reads
215
      the exception code out of the <TT
216
CLASS="LITERAL"
217
>cause</TT
218
> register
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.
223
      </P
224
></DD
225
><DT
226
>IA32</DT
227
><DD
228
><P
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.
239
      </P
240
></DD
241
><DT
242
>ARM</DT
243
><DD
244
><P
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
248
      <TT
249
CLASS="LITERAL"
250
>0x20</TT
251
> up, form the VSR table. Since each VSR
252
      is entered in a different CPU mode
253
      (<TT
254
CLASS="LITERAL"
255
>SVC,UNDEF,ABORT,IRQ or FIQ</TT
256
>) there has to be a
257
      different VSR for each exception that knows how to save the CPU
258
      state correctly.
259
      </P
260
></DD
261
></DL
262
></DIV
263
></DIV
264
><DIV
265
CLASS="NAVFOOTER"
266
><HR
267
ALIGN="LEFT"
268
WIDTH="100%"><TABLE
269
SUMMARY="Footer navigation table"
270
WIDTH="100%"
271
BORDER="0"
272
CELLPADDING="0"
273
CELLSPACING="0"
274
><TR
275
><TD
276
WIDTH="33%"
277
ALIGN="left"
278
VALIGN="top"
279
><A
280
HREF="hal-exception-handling.html"
281
ACCESSKEY="P"
282
>Prev</A
283
></TD
284
><TD
285
WIDTH="34%"
286
ALIGN="center"
287
VALIGN="top"
288
><A
289
HREF="ecos-ref.html"
290
ACCESSKEY="H"
291
>Home</A
292
></TD
293
><TD
294
WIDTH="33%"
295
ALIGN="right"
296
VALIGN="top"
297
><A
298
HREF="hal-default-synchronous-exception-handling.html"
299
ACCESSKEY="N"
300
>Next</A
301
></TD
302
></TR
303
><TR
304
><TD
305
WIDTH="33%"
306
ALIGN="left"
307
VALIGN="top"
308
>Exception Handling</TD
309
><TD
310
WIDTH="34%"
311
ALIGN="center"
312
VALIGN="top"
313
><A
314
HREF="hal-exception-handling.html"
315
ACCESSKEY="U"
316
>Up</A
317
></TD
318
><TD
319
WIDTH="33%"
320
ALIGN="right"
321
VALIGN="top"
322
>Default Synchronous Exception Handling</TD
323
></TR
324
></TABLE
325
></DIV
326
></BODY
327
></HTML
328
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.