 |
 |
 |
 |
 |
|
|
|
|
|
|
|
“Traps” are like “interrupts” in that they are events which are handled by the same hardware mechanism, and hence by similar software mechanisms.
“Traps” are unlike “interrupts” in that they occur as the result of events internal to the CPU, rather than externally. (In other systems the terminology “internal interrupt” and “external interrupt” is used to draw this distinction more forcefully.) Traps may occur unexpectedly as the result of hardware or power failures, or predictably and reproducibly, e.g. as the result of executing an illegal instruction or a “trap” instruction.
“Traps” are always recognised by the CPU immediately. They cannot be delayed in the way low priority interrupts may be. If you like, “traps” have an “interrupt priority” of eight.
“Trap” instructions may be deliberately inserted in user mode programs to catch the attention of the operating system with a request to perform a specified service. This mechanism is used as part of the facility known as “system calls”.
Like interrupts, traps result in the reloading of the PC and PS from a vector location, and the saving of the old values of the PC and PS in the current stack. Table 9.2 lists the vector locations for the various “trap” types.
vector |
trap type |
process |
location |
priority |
|
004 |
bus timeout |
7 |
010 |
illegal instruction |
7 |
014 |
bpt-trace |
7 |
020 |
iot |
7 |
024 |
power failure |
7 |
030 |
emulator trap instruction |
7 |
034 |
trap instruction |
7 |
114 |
11/10 parity |
7 |
240 |
programmed interrupt |
7 |
244 |
floating point error |
7 |
250 |
segmentation violation |
7 |
Table 9.2 Trap Vector Locations and Priorities
The contents of Tables 9.1 and 9.2 should be compared with the file “low.s” on Sheet 05. As noted earlier, this file is generated at each installation (along with the file “conf.c” (sheet 46)), as the product of the utility program “mkconf”, so as to reflect the actual set of peripherals installed.
|
|
|
|
|
|