int/iret

The SaarCPU features hardware interrupts (which, of course, are not part of the ISA) as well as software interrupts (int). Both hardware and software interrupts save the program counter, the accumulator and the flags. Program counter here means the address of the opcode of the instruction that would have been executed if there had not been an interrupt. In our microarchitecture, this is implemented using shadow registers (wx for the program counter, y for $\mathit{acc}$ and z for the flags). All other registers are to be saved by the interrupt handler. Interrupt instruction loads the interrupt code into $\mathit{acc}$ and sets the program counter to $0$ . Furthermore, it disables interrupts.

The interrupt return instruction restores the program counter, the accumulator and the flags. Furthermore, it enables interrupts.

Instruction	Encoding	Semantics	Cycles
(hardware interrupt)		see above and the control unit documentation	8
`int imm8`	`00 100 001` `imm8`	see above	7
`iret`	`00 101 001`	see above	4

Remarks

To meaningfully handle interrupts—the program counter is $0$ regardless of the interrupt code—there needs to be a case distinction on the interrupt code in $\mathit{acc}$ in the bootup ROM. To distinguish between bootup and interrupts the interrupt code $0$ is reserved. reset will always load $0$ into $\mathit{acc}$ . Hence, the bootup ROM could start like this:

  cmp acc, 0
  je boot
  jmp 0x1000

boot:
  ; ...

Here, the main interrupt handling would be done in the code at 0x1000, which is in the main memory. This makes the active interrupt handlers customizable.

Note that interrupts themselves do not affect the stack. The interrupt handler might still do so, however one needs to ensure that the stack pointer points to valid memory locations then. This can be achieved using an invariant in the software (always disabling interrupts when sp is invalid) or by using a separate stack for interrupts.

Because there is no stack for interrupts, they also cannot be nested. Since both hardware and software interrupts disable further interrupts until iret, this usually does not cause problems. Enabling interrupts in the interrupt handler using sti, however, causes undefined behavior.

The cli instruction does not affect software interrupts. The sequence cli; int 42 would still cause an interrupt. Note furthermore that returning from the interrupt using iret would re-enable interrupts.

For more details on hardware interrupts, refer to the control unit documentation.

Remarks​

Remarks