Hardware Reference
In-Depth Information
own CPU. This style of programming makes programming some applications eas-
ier. It also is useful for testing software that will later actually run on a multiproc-
essor.
Neither the usual
CALL
nor the usual
RETURN
instruction works for calling
coroutines, because the address to branch to comes from the stack like a return,
but, unlike a return, the coroutine call itself puts a return address somewhere for
the subsequent return to it. It would be nice if there were an instruction to ex-
change the top of the stack with the program counter. In detail, this instruction
would first pop the old return address off the stack into an internal register, then
push the program counter onto the stack, and finally, copy the internal register into
the program counter. Because one word is popped off the stack and one word is
pushed onto the stack, the stack pointer does not change. This instruction rarely
exists, so in most cases it has to be simulated as several instructions.
A
trap
is a kind of automatic procedure call initiated by some condition
caused by the program, usually an important but rarely occurring condition. A
good example is overflow. On many computers, if the result of an arithmetic oper-
ation exceeds the largest number that can be represented, a trap occurs, meaning
that the flow of control is switched to some fixed memory location instead of con-
tinuing in sequence. At that fixed location is a branch to a procedure called the
trap handler
, which performs some appropriate action, such as printing an error
message. If the result of an operation is within range, no trap occurs.
The essential point about a trap is that it is initiated by some exceptional condi-
tion caused by the program itself and detected by the hardware or microprogram.
An alternative method of handling overflow is to have a 1-bit register that is set to
1 whenever an overflow occurs. A programmer who wants to check for overflow
must include an explicit ''branch if overflow bit is set'' instruction after every
arithmetic instruction. Doing so is both slow and wasteful of space. Traps save
both time and memory compared with explicit programmer-controlled checking.
The trap may be implemented by an explicit test performed by the micropro-
gram (or hardware). If an overflow is detected, the trap address is loaded into the
program counter. What is a trap at one level may be under program control at a
lower level. Having the microprogram make the test still saves time compared to a
programmer test, because it can be easily overlapped with something else. It also
saves memory, because it need occur only in one place, for example, the main loop
of the microprogram, independent of how many arithmetic instructions occur in the
main program.
A few of the common conditions that can cause traps are floating-point over-
flow, floating-point underflow, integer overflow, protection violation, undefined
opcode, stack overflow, attempt to start a nonexistent I/O device, attempt to fetch a
word from an odd-numbered address, and division by zero.
