I am talking about things at the core level.
As far as I understand, the controller core just executes instructions which are fetched from the memory (Fetch – Decode – Execute). When an Interrupt arrives, how does the core/ALU decide to jump to the ISR?
Because we, or the compiler, don't add any instruction to poll the interrupt status – then how does it know that an interrupt needs to be served?
Best Answer
What you are missing is that the core does do more than just execute opcodes that are fetched from memory. It has specific logic in it to implement interrupts.
When the interrupt detection hardware asserts the signal that says it's time to take a interrupt, usually a special instruction is jammed into the core that was never fetched from memory. In most cases this is a CALL instruction to the interrupt vector address. This uses the existing instruction execution mechanism to save the current PC onto the call stack, and change it to the interrupt vector address. It also deals with discarding pre-fetched instructions and the like.
The special interrupt-taking logic also has to disable interrupts in such a way so that the same interrupt condition doesn't cause another call to the interrupt vector address next cycle. Different processors have different ways of handling this. The simplest is to just gloablly disable interrupts, requiring the software to re-enable them at the end of the interrupt service routine. Other processors have a interrupt priority level. This level is bumped so that only interrupt conditions of higher priority can cause a new interrupt. The interrupt priority is then something that is automatically saved along with the CALL return address, and restored when the code returns from the interrupt.