Polled interrupts: how does the CPU know which ISR to run?

  • Thread starter Thread starter eliotsbowe
  • Start date Start date
  • Tags Tags
    cpu
Click For Summary

Discussion Overview

The discussion centers on how a CPU determines which Interrupt Service Routine (ISR) to execute in the context of polled interrupts, contrasting it with vectored interrupts. Participants explore the mechanisms involved in identifying ISRs without an interrupt vector, considering both theoretical and practical implications.

Discussion Character

  • Technical explanation
  • Conceptual clarification
  • Debate/contested

Main Points Raised

  • One participant notes that in vectored interrupts, a device sends a specific code to the CPU, while in polled interrupts, the CPU must determine the ISR based on the interrupt register contents.
  • Another participant suggests that the CPU may use an interrupt register that indicates which interrupts are pending, possibly employing a priority encoder to identify the highest priority interrupt.
  • It is mentioned that the code must determine which ISR to run based on the state of the device, which can be managed using a switch variable or function pointers in programming.
  • A participant highlights that even in hardware interrupts, some CPUs, like ARM, may require reading an interrupt register to identify the ISR, indicating a similarity to the polling approach.
  • One participant shares their experience with polling in real-time systems, emphasizing its predictability and the challenges it presents in design and implementation.

Areas of Agreement / Disagreement

Participants express varying views on the mechanisms of polled interrupts and their implementation. There is no consensus on a single method or approach, as different CPUs and hardware configurations may influence the behavior.

Contextual Notes

The discussion reflects limitations in understanding specific hardware implementations and the assumptions about how polling and interrupt handling are structured across different systems.

eliotsbowe
Messages
34
Reaction score
0
Hello, may someone help me to understand this?
I know that in vectored interrupts, a device asks the CPU to run a certain ISR by sending a specific code. Now, in polled interrupts there's no interrupt vector. So how does the CPU know what's the Interrupt Service Routine to be run?
Perhaps there's only one Interrupt Service Routine per device? Or maybe each device can request one Routine per Interrupt Priority Level, so that the CPU knows what to do just by recognizing the device and the Priority Level of the request?



Thanks a lot for your help.
 
Technology news on Phys.org
eliotsbowe said:
So how does the CPU know what's the Interrupt Service Routine to be run?
Depends on the CPU and the related hardware. Generally there will be an interrupt register to indicate which interrupts are pending. The interrrupt register could use a separate bit for each possible interrupt, or the hardware could have a priority encoder that returns a value representing the highest priority pending interrupt.

For polled interrupts, the CPU won't know which interrupt to run, instead the code will have to determine which interrupt to run based on the interrupt register contents. In addition, each interrupt handler may be keeping track of the "state" of a device, in order to decide which code segment should be used to handle the current interrupt as a device goes thorugh a series of states. In C, this can be done with a switch variable and switch / case statement or one or more pointers to functions and calls via those pointers to functions, where the switch variable or pointers to function are updated as the state of a device changes.

Even when using hardware interrupts, some CPUs, such as the ARM, only have a single interrupt vector (there's also another fast interrupt vector), so the code has to read an interrupt register to determine which routine to call even when using interrupts instead of polling.
 
Last edited:
got it, thanks!
 
It is possible to simulate interrupts using "polling", which is basically a loop. Each time through the loop, the code looks down through a series of options and acts on the ones that need attention. When writing real-time code, polling has the advantage of allowing a programmer to know EXACTLY what the worst-case time for the loop will be. However, it takes a great deal of patience, planning and care to design.

I used to write code for lightwave systems at Bell Labs. Polling was the only way we could guarantee that everything would always get handled withing the required tolerances. But it was hard for some programmers to wrap their heads around it. We had about 5 different Motorola 68000 processors; they communicated with each other using shared memory, all by polling (no locking!). Each memory location could only be written by one processor, and the others could only read from that location. The readers would "debounce" (read multiple times, to see if changes occurred) before using new values.

The entire scheme was simple and did not involve operating system calls or hardware interrupts.
 

Similar threads

Replies
6
Views
4K
Replies
7
Views
3K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 11 ·
Replies
11
Views
7K
  • · Replies 8 ·
Replies
8
Views
2K
  • Sticky
  • · Replies 13 ·
Replies
13
Views
8K
Replies
7
Views
3K
  • · Replies 30 ·
2
Replies
30
Views
4K
Replies
4
Views
2K