How are Interrupts handled in a processor - a detailed view

Interrupt handling has always been one of my favorite topics to dig into. Even though the concept may appear so simple, there is always something exciting I learn each time I look into it. One of the reasons why interrupts could be so fascinating is, it acts as a window that opens into a wider horizon of the Operating Systems and hardware architecture. Questions like how is the contention is maintained between interrupt and thread context, how data consistency is maintained between the threads and interrupts really require us to go deep into the processor architecture to get the right insight.

I am sharing the notes I had prepared during my in-depth studies on processors. Do excuse my badly formatted text, as I was a bit hard-pressed for time. But I hope you enjoy reading about them as much I did while exploring them.

In-depth analysis of Interrupts.

•Interrupts are asynchronous signals directed to the CPU, requesting it to stop its current execution and service what the interrupt is asking for.

•Interrupts can be either external to the CPU and can be raised by peripherals like UART, SPI slave devices, USB, memory blocks etc.

•Interrupts can be also raised from internal processes to CPUs. These are Software Interrupts.

•Traps and exceptions – When the CPU finds itself in difficult situations like divide by zero errors, faulty memory access etc., then the CPU can itself raise signals that are very similar to interrupts.

•Interrupts can be maskable or non-maskable. That is if an interrupt is configured as maskable, the CPU can choose to ignore or disable it.

•If an interrupt is non-maskable, then the CPU must service it at any cost.

•CPUs have two modes of execution, called the Thread mode and Interrupt mode.

•The normal programs that we execute runs in Thread mode.

•When an Interrupt is raised, the CPU immediately switches to Interrupt mode.

•It must be remembered that an interrupt occurs asynchronously to the CPU. That is CPU is not aware as to when the interrupt can arrive.

•That is from the perspective of the CPU, an interrupt can occur at any point in time. It may or may never occur.

•So there no point specifically waiting for the interrupt.

•The CPU behaves identically to all interrupts. That is, there are certain fixed steps that will be followed when an interrupt occurs.

•This is pretty much constant throughout all types of controllers and processors.

•Each interrupt can have an interrupt service routine associated with it.

•Interrupt service routine looks very similar to a function, where some operations occur.

•An interrupt request is generated by a peripheral or software process to seek CPU's attention.

•Some processors have a dedicated unit (ARM cortex) called Programmable Interrupt Controller (PIC) which is directly connected with every peripheral that can generate an interrupt via a physical wire.

•The PIC identifies the nature of the interrupt. For example, PIC identifies the source of the interrupt from the dedicated hardware line on which it occurs.

•For example, if the interrupt is raised on line no 7, then that is already pre-assigned to ADC. If an interrupt occurs on line no 12, then that would belong to UART and so on.

•This way, the PIC would be able to identify the source of the interrupt from the unique ID.

•This unique ID is known as Interrupt request ID (IRQ ID). 

•The PIC immediately informs the CPU that an interrupt has been raised and requires servicing.

•Get the Interrupt request ID from the PIC and map it to a global data structure called the Interrupt Vector Table (IVT).

• Every processor has an IVT that is stored in a predefined memory location.

•IVT is a directory where all the information about the interrupt is stored.

•It talks about the source of the interrupt, its priority if the interrupt is maskable or non-maskable and finally, the address pointer to the Interrupt service routine (ISR).

•Each interrupt is assigned a priority of operation. Assume, in a very rare case where two interrupts were raised at the same instant. How would the CPU arbitrate interrupt servicing in this case?

•That is when interrupt priority is used. An interrupt of higher priority is obviously given higher preference.

•Interrupt Service routine (ISR) is a software process that is invoked by the CPU to service an interrupt.

•In simpler terms, an ISR is basically the software routine (function like) that is run when an interrupt occurs.

•It contains the operations that the peripheral wants to execute for which it raises an interrupt.

•The CPU does something known as context switching the moment it notices an interrupt request.

•Recall that interrupts is asynchronous to the CPU. That is, the CPU does not know when the interrupt can arrive.

•The CPU would be happily executing a thread (usually any task) when the interrupt arrives.

•CPU does a context switching, which involves saving the current execution state, so that it may return back to the exact same point once the interrupt execution is over.

•Context switching involves saving the states of the stack pointer, instruction register, program counter, and status register.

•Once the CPU has completed context switching, it jumps to the address pointer of the corresponding Interrupt service routine (ISR) present in the Interrupt vector table.

•Once the CPU control enters the ISR, it completes the execution and returns from it.

•CPU now reloads the registers it had context switched out before entering the ISR.

•This way it can resume the task it was doing before the arrival of the interrupt.