• Aucun résultat trouvé

Exception Vectors: Where Exception Handling StartsStarts

Dans le document 0.1 Style and Limits (Page 127-131)

Exceptions, Interrupts, and Initialization

5.3 Exception Vectors: Where Exception Handling StartsStarts

Most CISC processors have hardware (or concealed microcode) that analyzes an exception, dispatching the CPU to different entry points according to what kind of exception happened. A MIPS CPU does very little of this. If that seems a serious omission, consider the following.

Firstly, vectored interrupts are not as useful in practice as we might hope.

In most operating systems, interrupt handlers share code (for saving reg-isters and such like) and it is common for CISC microcode to spend time dispatching to different interrupt entry points, where OS software loads a code number and jumps back to a common handler.

106 5.3. Exception Vectors: Where Exception Handling Starts

Secondly, it’s difficult to envision much exception analysis being done by pure hardware rather than microcode; on a RISC CPU ordinary code is fast enough to be used in preference.

Here and elsewhere, you should bear in mind just how fast CPUs of the RISC generation are compared with their peripherals. A useful interrupt rou-tine is going to have to read/write some external registers, and on a mid-90s CPU that external bus cycle is likely to take 20-50 internal clock cycles. It’s easy to write interrupt dispatch code on a MIPS CPU that will be Faster than a single peripheral access — so this is unlikely to be a performance bottle-neck.1

However, even in MIPS not all exceptions were ever equal, and differences have grown as the architecture has developed. So we can make some distinc-tions:

• TLB refill of user-privilege address: There is one particularly frequent exception in a protected OS, related to the address translation system (see Chapter 6). The TLB hardware only holds a modest number of address translations, and in a heavily used system running a virtual memory OS it’s common for the application program to run on to an address whose translation is not recorded in the TLB — an event called a TLB miss (because the TLB is used as a software-managed cache).

The use of software to handle this condition was controversial when RISC CPUs were introduced, and MIPS CPUs provide significant support for a preferred scheme for TLB refill. The hardware helps out enough that the exception handler for the preferred refill scheme usually runs in about 13 clock cycles.

As part of this, common classes of TLB refill are given an entry point different from all other exceptions so that the finely tuned refill code doesn’t have to waste time figuring out what kind of exception has hap-pened.

• TLB refill for 64-bit address spaces: Memory translation for tasks want-ing to take advantage of the larger program address space available on 64- bit CPUs uses a slightly different register layout and a different TLB refill routine; MIPS calls this XTLB refill (“X” for extended, I guess).

Again, a desire to keep this very efficient makes a separate entry point useful.

• Uncached alternative entry points: For good performance on exceptions the interrupt entry point must be in cached memory, but this is highly undesirable during system bootstrap; from reset or power-up, the caches are unusable until initialized. If you want a robust and self-diagnosing startup sequence, you have to use uncached read-only memory entry

1We labor this point because the lack of vectored interrupt hardware has been cited by some of the MIPS competitors as a problem for embedded systems.

points for exceptions detected in early bootstrap. In MIPS CPUs there is no uncached “mode” — there ace uncached program memory regions instead — so there’s a mode bit SR(BEV) that reallocates the exception entry points into the uncached, startup-safe kseg1 region.

• Parity/ECC error: R4000 and later CPUs detect a data error (usually in data arriving from main memory, but often not noticed until it’s used from cache) and take a trap. It would be silly to vector through a cached location to handle a cache error, so regardless of the state of SR(BEV) the cache error exception entry point is in uncached space.

• Reset: For many purposes it makes sense to see reset as another excep-tion, particularly when the R4x00 and later CPUs use the same entry point for cold reset (where the CPU gets completely reconfigured; indis-tinguishable from power-up) and warm reset (where the software gets completely reinitialized). In fact, nonmaskable interrupt (NMI) turns out to be a slightly weaker version of warm reset, differing only in that it waits for an instruction to finish before taking effect.

Table 5.1: Hardwired reset and exception entry points for MIPS CPU

Exception type Entry point

SR(BEV) == 0 SR(BEV) == 1 Program Physical Program Physical

Reset, NMI 0xBFC0 0000 0x1FC0 0000

TLB refill, 32-bit task 0x8000 0000 0x000 0xBFC0 0200 0x1FC0 0200 XTLB refill, 64-bit task 0x8000 0080 0x080 0xBFC0 0280 0x1FC0 0280 Cache error (R4x00 and later) 0xA000 0100 0x100 0xBFC0 0300 0x1FC0 0300 Interrupt (some QED CPUs only) 0x8000 0200 0x200 0xBFC0 0400 0x1FC0 0400 All other exceptions 0x8000 0180 0x180 0xBFC0 0380 0x1FC0 0380

All exception entry points lie in untranslated regions of the MIPS memory map, in kseg1 for uncached entry points and kseg0 for cached ones. In these areas the nominal 32-bit addresses given in Table 5.1 extend to a 64-bit memory map by sign extension: The program address 0x8000 0000 in the 32-bit view is the same as0xFFFF FFFF 8000 0000in the 64-bit view. Table 5.1 describes the entry points with just 32-bit addresses.

Presumably the 128-byte (0x80) gap between the exception vectors occurs because the MIPS architects felt that 32 instructions would be enough to code the basic exception routine, saving a branch instruction without wasting too much memory!

Here’s what a MIPS CPU does when it decides to take an exception:

1. It sets up EPC to point to the restart location.

108 5.3. Exception Vectors: Where Exception Handling Starts

2. The CPU changes into kernel (high-privilege) mode and disables inter-rupts. The way this is done is different in 32-bit (pre-R4x00) and 64-bit MIPS CPUs — see the following for details.

3. Causeis set up so that software can see the reason for the exception. On address exceptions BadVaddr is also set. Memory management system exceptions set up some of the MMU registers too; more details are given in Chapter6.

4. The CPU then starts fetching instructions from the exception entry point, and everything else is up to software.

Exception

End-of-Exception rfe instruction

KUo IEo KUp IEp KUc IEc

KUo IEo KUp IEp KUc IEc

KUo IEo KUp IEp KUc IEc

KUo IEo KUp IEp KUc IEc

Figure 5.1: Priviledge state mini-stack for pre-R4x00 MIPS CPUs

We said that the mechanism used to change into the high-privilege/ interrupts-disabled state changed between early and later MIPS CPUs. This is one of the few examples where the CPU actually got simpler.

Pre-R4x00 32-bit CPUs have a kernel/user privilege bit and an inter-rupt enable/disable bit. Inside the SR register there is a three-entry stack whose operation is illustrated by Figure 5.1; on an exception the existing 2-bit state is pushed and replaced by kernel mode with interrupts off. The end-of-exception instruction rfe (restore from exception) pops the stack and restores the CPU to its pre-exception condition.

System software can use this (under very limited circumstances) to handle a nested exception within a primitive exception routine that makes no soft-ware provision for saving and restoring SR; this allows simplification of the frequently called TLB miss exception (see Section 6.7)

On the R4000 and subsequent CPUs, the normal privilege field is 2 bits long, due to the introduction of the intermediate supervisor privilege level.

An exception doesn’t change this field; it just sets the SR(EXL) (exception level) bit, which has the side effects of forcing kernel mode and disabling interrupts. Very short exception routines can run entirely at this exception level (in exception mode, as we’ll sometimes say) and need never touch the rest of SR. For more conventional exception handlers, which save state and pass control over to more complex software, exception level provides a cover under which system software can save the old SRvalue in safety.

It turns out that the R4x00 model can also be used to allow an exception within the primitive TLB miss handler, but we’ll talk more about how that’s done when we get to it.

Dans le document 0.1 Style and Limits (Page 127-131)