From 9698e82369db966b12b5a0a0fa52515b2ffe41d0 Mon Sep 17 00:00:00 2001 From: Wojtek Kosior Date: Sat, 18 Jan 2020 04:11:28 +0100 Subject: explain exception vector --- Exception-vector-explained.txt | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Exception-vector-explained.txt diff --git a/Exception-vector-explained.txt b/Exception-vector-explained.txt new file mode 100644 index 0000000..eb382a2 --- /dev/null +++ b/Exception-vector-explained.txt @@ -0,0 +1,38 @@ +Whenever some illegal operation (attempt to execute undefined instruction, attempt to access memory with insufficient permission, etc.) happens or some peripheral device "messages" the ARM core, that something important happened, an exception occurs. Exception is something, that pauses normal execution and passes control to the (specific part of) operating system. +Upon an exception, several things happen: +1. Processor mode changes. +2. CPSR gets saved into new mode's SPSR . +3. pc (incremented by some value) is saved into new mode's lr. +4. Execution jumps to an entry in the exception vectors table specific to the exception. + +Each exception type is taken to it's specific mode. Types and their modes are: +1. Reset and supervisor mode. +2. Undefined instruction and undefined mode. +3. Supervisor call and supervisor mode. +4. Prefetch abort and abort mode. +5. Data abort and abort mode. +6. Hypervisor trap and hypervisor mode (not used normally, only with extensions). +7. IRQ and IRQ mode. +8. FIQ and FIQ mode. + +The new value of the pc (the address, to which the exception "jumps") is the address of nth instruction from exceptiom base address, which, undes simplest settings, is 0x0 (bottom of virtual address space ). N depends on the exception type. It is: +· 1 for reset +· 2 for undefined instruction +· 3 for supervisor call +· 4 for prefetch abort +· 5 for data abort +· 6 for hypervisor trap (not used here) +· 7 for IRQ +· 8 for FIQ + +Those 8 instructions constitute the exception vectors table. As the instruction follow one another, each of them should be a branch to some exception-handling routine. In fact, on other architectures often the exception vector table holds raw addresses of where to jump instead of actual instructions, as here. + +Bottom of virtual address space can be changed to some other value by manipulating the contents of SCTLR and VBAR coprocessor registers. + +On exception entry, the registers r0-r12 contain values used by the code that was executing before. In order for the exception handler to perform some action and return to that code, those registered can be preserved in memory. Some compilers can automatically generate appropriate prologue and epilogue for handler-functions, that will preserve the right registers (see ; we're not using this feature in our project). + +Having old CPSR in SPSR and old pc in lr is helpful, when after handling the exception, the handler needs to return to the code that was executing before. There are 2 special instructions, subs and ldm ^ (load multiple with a dash ^), that, when used to change the pc (and therefore perform a jump) cause the SPSR to be copied into CPSR. As bits of CPSR determine the current execution mode, this causes the mode to be change to that from before the exception. In short, subs and ldm ^ are the instructions to use to return from exceptions. + +As noted eariler, upon exception entry an incremented value of pc is stored in lr. By how much it is incremented, depends on exception type and execution state. For example, entering undefined instruction exception for thumb state places in undef's lr the problematic instruction's address + 2, while taking this exception from ARM state places in undef's lr that instruction's address + 4 (see full table in paragraph B1.8.3 of armv7-ar_arm ). + +It's worth noting, that while our implementation of exception handlers () also sets the stack pointer (sp) upon each exception entry, a kernel could be written, where this wouldn't be done, as each mode enterable by exception has it's own sp. -- cgit v1.2.3 be95980b375884cca79d7f8896891caace'>gnu: fc-host-tools: Update to 14....Danny Milosavljevic 2020-12-21gnu: sdcc: Update to 4.0.0....Simon South 2020-12-21gnu: sdcc: Expand comment regarding GPUTILS and PIC ports....Simon South 2020-12-21gnu: sdcc: Correct name of phase....Simon South 2020-12-21gnu: sdcc: Revise synopsis and description....Simon South 2020-12-21gnu: sdcc: Specify complete set of licenses....Simon South 2020-12-21gnu: sdcc: Move to embedded.scm....Simon South 2020-12-21gnu: Add μCsim....Simon South 2020-12-01gnu: openocd: Fix build....Morgan Smith 2020-11-19gnu: Don't append '.git' to GitHub uris....Efraim Flashner 2020-11-16gnu: gcc-vc4: Update to commit 0fe4b83897341742f9df65797474cb0feab4b377....Danny Milosavljevic 2020-11-10gnu: jimtcl: Update to 0.80....Tobias Geerinckx-Rice