14

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?

Swanand
  • 3,245
  • 5
  • 28
  • 45

4 Answers4

15

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.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • 1
    Often, it is not a ordinary `CALL` instruction, as interrupts are terminated in a different way (cf. `RET` vs. `RETI`). – glglgl Dec 17 '14 at 08:09
  • 1
    Can I safely assume that when that Interrupt detection hardware asserts the signal, Instead of Memory, CPU gets instruction from somewhere else to jump... Like a Switch maybe... When Switch is OFF, Fetch instruction from Memory and when switch is ON, Execute this instruction? – Swanand Dec 18 '14 at 08:00
4

Commonly in the modern microcontrollers there is a dedicated Interrupt Controller (IC) unit who is in charge of managing interrupts. In addition each peripheral component has an interrupt output(s) which is going from 0 to 1 (or vice versa) if some condition apply (for example this peripheral completed some work). This output is connected to the interrupt controller. The Core CPU can tell the IC either to ignore this specific interrupt (mask it) or to notify the MCU whenever it happens by triggering specific signals, and then the MCU decides what to do with it. The common way is have the IC to tell to MCU which interrupt did happen and jump to corresponding handling code.

Eugene Sh.
  • 9,986
  • 2
  • 26
  • 41
2

There is hardware in the computer core that jams a new value into the program counter that corresponds to the particular interrupt that has been triggered. In order to remember where to come back to after the interrupt routine is completed the current value in the program counter is pushed into the stack before the hardware jams the interrupt address into the program counter. When the interrupt routine is completed the original value of the program counter is restored back out of the stack.

The values to jam into the program counter at interrupt time are usually determined by one of two schemes. One approach jams a fixed address for each interrupt type into the program counter and the computer core then starts executing from that fixed location. The space at the fixed location is often limited in size so it is common to code a jump instruction at the fixed addresses that go over to the actual interrupt service location. The other scheme uses something called an interrupt vector table. Here the hardware generates a fixed address offset into the vector table based on interrupt type. The hardware then pulls out the content at that table location and uses that value as an address to jam into the program counter. The addresses in the table have of course been loaded there according to where the interrupt service routines are located in the memory.

Michael Karas
  • 56,889
  • 3
  • 70
  • 138
2

The controller has a register for the program counter that keeps track of the address where the next-to-be-executed instruction is stored. (This register is also written when a jump is executed.)

The controller has an interrupt vector (or sometimes more than one, dependent on the type of interrupt), which is the address where the ISR is stored. This address is always the same - it's like the reset vector, where the program starts.

(Often, there's a jump instruction stored at this vector that jumps to the actual code to execute, since the space at the vector is not enough to store the whole procedure. However, the important thing is that the ISR is always located at the same position.)

When an interrupt occurs, there's some dedicated hardware in the controller that writes the program counter with the interrupt vector. Then, when the controller reaches the next instruction cycle, it fetches the instruction from the address that is pointed to by the program counter (so, the interrupt vector).

(In one instruction cycle of the controller there are different tasks it performs: it fetches the next instruction from the address pointed to by the program counter; it increases the program counter; it decodes the instruction, and executes it.)