Interrupts in microprocessors
Asked today
Active today
Viewed 87 times
2
This might be a very trivial question, but I was unable to find a concise answer to it. For non maskable interrupts, are the interrupts handled immediately while the current instruction is getting executed? Or it waits for the current instruction to get executed and then handles interrupts. Also for non maskable interrupts, when the interrupt flag is set to 1, does it replicate the maskable interrupt situation?
ShareCite
EditFollowFlag
asked 9 hours ago
3122 bronze badges
New contributor
- 7wouldn’t that depend on the microprocessor architecture? – jsotola 9 hours ago
- 5For the vast majority of architectures, interrupts are handled between instructions. – Dave Tweed 8 hours ago
- 1IMO, the CPU would hardly recover if it would be interrupted at any time. – Marko Buršič 4 hours ago
- @MarkoBuršič: Some CPUs do support interrupting within an instruction. It requires a much larger stack frame to preserve all of the necessary internal state. This capability is essential for supporting virtual memory, where a bus error (e.g., page not present) can occur on any memory cycle during an instruction. For example, this is they key difference between the 68000 and the 68010. – Dave Tweed 15 mins ago
- In the old days, usually the cpu with onbly one core would only check any interrupt after executing the current instruction. Nowadays cpus are often multicore, eg, for the two core US$4 Rpi Pico, it is easy to assign one core for handling (perhaps looping) special events (in the strict sense, should no longer be called interrupting events) in the background, and the main core doing the main business. In other words, no more worries of any processes being interrupts. More cores can handle more dedicated interrupt events. I recommend learners experiment with Pico’s two core interrupt. – tlfong01 4 mins ago Edit
3 Answers
1
The precise details of how exactly interrupts are handled varies from processor to processor. Nevertheless we can simplify the operations for ease of understanding.
At its simplest, a processor basically:
#fetch next instruction
#execute an instruction
rinse and repeat.
For interrupts, we can evaluate these before fetching an instruction. So the operation would be something like this:
if interrupt pending, do interrupt service (which is basically a function call with a little bit extra)
else
#fetch next instruction
#execute instruction
rinse and repeat.
Where you have multiple interrupt sources (including non-maskable) you need a means of resolving priority. Non-maskable has the highest priority.
Some architectures implement interruptible instructions – 68k comes to mind. This can add an extra layer of complexity as you also need to save the processor micro state as well as the cpu state. If a potential write is involved, then that needs to be specially managed – was the instruction interrupted before the write or after?
I’d suggest you investigate cpu architectures like the ARM Cortex and RISC-V to see how they handle interrupts in a modern context.
In summary, you could simply describe an interrupt as a hardware conditional function call.
ShareCite
EditFollowFlag
answered 8 hours ago
4,90822 gold badges55 silver badges1111 bronze badges
0
The best way to think about interrupts, is in terms of where the next instruction comes from. Most architectures have an Instruction Address multiplexer, which chooses one from a number of sources.
For much of the time, the processor steps linearly through the code, executing instructions sequentially. The register that holds the address of the currently executing instruction is actually called the Program Counter (abbreviated to PC) in many architectures, to reflect the fact that it just counts linearly through the code.
The PC provides a PC+1 input to the Instruction Address multiplexer.
From time to time, this linear operation is changed by a Branch instruction, which modifies the normal program flow. This could be a Jump, whether conditional or unconditional, a Call, or a Return instruction. The branch destination addresses come from the branch instruction itself, or are popped off of a Return Address stack.
The call instruction does additional work, putting the PC+1 onto a the return address stack, matched by the return which pops it. These are typically used in pairs, around a function call.
These software branch instructions provide another set of inputs to the Instruction Address multiplexer.
An interrupt is a hardware branch. The destination address usually comes from an Interrupt Vector table, though the non-maskable one is often hardwired.
The interrupt logic handles whether any interrupts are masked, and chooses the highest priority one if there are multiple interrupts. This is totally dependent on the design of the processor, look at the data sheet for the one you are using to see the detail of what individual flags do.
The interrupt instruction puts the PC+1 onto a return address stack just like the software call, though often a different one to the software call. The interrupt function is often required to end with a Return from Interrupt instruction, which pops this separate stack.
It can be seen then that an interrupt function is practically equivalent to an ordinary software function, but called by a hardware event instead of a software instruction.
ShareCite
EditFollowFlag
answered 3 hours ago
136k33 gold badges154154 silver badges336336 bronze badges
0
Interrupts, maskable or not, generally need to be processed fast. Processing them fast means that no significant amount of time should be used saving and restoring state for resuming normal operation. That generally makes interrupts be implemented as function calls that only save the instruction pointer, relying on the interrupt routine itself to save anything else it may need. Some processors have a separate slate of registers (or memory-mapped registers where just relocating the register area will work) for this, but typically interrupts may be prioritised and nested so that it is usual to reenable interrupts before executing the bulk of the interrupt processing routine, and in this case there is no definite limit of extra registers you may need to switch in and out.
So usually state is saved externally to the processor and costs time to transfer there.
For things like page faults in processors implementing demand-paged virtual memory, saving the whole processor state is necessary.
So the interrupt latency generally is a whole instruction. For CPUs that have instructions with indefinite length, like the memory/string/IO repeat instructions of the x86 architecture, the instructions tend to be designed in a manner that an interrupt can return to the start of such an instruction interrupted during unfinished business and operation will resume there properly. So while the instruction-sized latency usually leads to the next instruction’s address getting pushed to the return stack, those special instructions can be interrupted while not finished and then the current instruction’s address is getting pushed, leading to an additional opcode fetch upon returning from the interrupt that would not have been necessary otherwise.
So the instruction granularity of interrupt routines can come with modifications, but it is generally what to reckon with.
ShareCite
EditFollowFlag
answered 3 hours ago
1
Categories: Uncategorized
tlfong01.blog 