An interrupt is a way of dealing with asynchronous computing that doesn’t involve polling. It can be implemented through hardware, firmware, and software.
The idea is instead of having the CPU stall while waiting for a certain external operation or side-effect to complete (polling), we instead let the external device or routine inform us when it is done, and in the meantime continue operating as usual on anything that doesn’t depend on the result of that operation.
Functioning
A CPU encounters an instruction that is marked as asynchronous for some reason or another. A common example is waiting for a disk read. The operating system dispatches a call to read from the disk, and in the meantime, the code operates as usual.
At the end of every CPU cycle, the CPU checks to see if a special register contains a flag signaling that an interrupt has occurred. If it does contain that flag, it will jump to a procedure that indicates what to do, called the interrupt service routine. The address of that routine is determined by another register that contains the address of that jump table, combined with a register that contains the id of the controller that signaled the interrupt. Those three registers are the:
- isDeviceInterrupting
- interruptVectorBase
- interruptController
Registers respectively.
Because the call is literally interrupting what we’re doing, we also need to effectively back up the data currently in our registers so that when the program resumes after the interrupt jump, so we have the same state as before.
Info
Non-testable
In reality, the CPU checks for interrupts at very specific points in the CPU cycle. The controller IOs also do not write directly to the CPU registers, that would be a bit of an architectural nightmare. But the simplified version of CSPC 213 does.