doc/html/ref/hal-vectors-and-vsrs.html

   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.               -->
   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 >