My understanding of interrupts is that they're set in code to signal the processor when an event occurs. When an interrupt happens, the processor pauses its current task, jumps to the interrupt service routine (ISR), handles the event, and then returns to the main function where it left off. I'm curious about how and where the processor stores the ongoing task before jumping to the ISR. Can someone explain this process for any controllers like 8051, PIC, or ARM?

 

At the minimum, the processor hardware responds to an interrupt by storing the current program counter value on a stack reserved for that purpose before loading the program counter with the address of the interrupt service routine. A 'return-from-interrupt' command makes the processor pop the interrupt stack and load the original program counter so that code continues as before the interrupt.

Storing 'the current task' may require extra code in the interrupt service routine to save further details of current state than the processor automatically saves.

 

On an ARM, the return address (where to resume) goes in the LR, and R1, R2, R3 and R12 are stored on the stack.
So the interrupt routine may use R1-R3 and R12, but if it uses any other registers, it must restore them to their original values before returning.

 

My understanding of interrupts is that they're set in code to signal the processor when an event occurs. When an interrupt happens, the processor pauses its current task, jumps to the interrupt service routine (ISR), handles the event, and then returns to the main function where it left off. I'm curious about how and where the processor stores the ongoing task before jumping to the ISR. Can someone explain this process for any controllers like 8051, PIC, or ARM?

Yes, The ongoing function usually has a stack-frame. Depending on variable scope, the memory is kept on the stack in the stack frame or in the allocatable space (aka the 'heap'). When exiting a function/procedure, the stack-frame is popped off for that function (not really, it's just returned to the heap) and previous code resumes.

This is not necessarily universal, but is among the most common way this is done. If you really want to understand this, you want to learn how a compiler compiles code- the symbol table, and primarily the linking and stack-frame/addressing aspects.