What about interrupts An introduction to the basic
What about ‘interrupts’? An introduction to the basic issues affecting the design of code that performs servicing of interrupts
Recall the PC components Central Processing Unit Main Memory system bus I/O device These peripheral I/O components act autonomously (i. e. , independently of whatever the CPU might happen to be doing at any given moment)
Recall the ‘Fetch-Execute’ cycle Fetch next instruction Advance instruction-pointer Decode fetched instruction Execute decoded instruction no INTR ? yes Interrupt Service Routine
Compare-and-branch • We make frequent use of program-loops, such as this one: xor %bx, %bx # initialize array-index again: … # <body of the loop goes here> … inc %bx # increment array-index cmp $16, %bx # index still below 16? jb again # yes, go through again … # otherwise ‘fall through’
The ‘cmp’ instruction • The instruction ‘cmp’ causes the CPU to perform internally a subtraction-operation • Example: sub $16, %bx • The value 16 is subtacted from the value in register BX (but without changing BX) • However, the values of bits in the FLAGS register DO get changed, so as to reflect the result of that subtraction-operation!
The FLAGS register Status-flags O F D F I F T F S F Z F 0 A F 0 P F 1 C F Control-flags Legend: ZF = Zero Flag SF = Sign Flag CF = Carry Flag PF = Parity Flag OF = Overflow Flag AF = Auxiliary Flag TF = Trap Flag IF = Interrupt Flag DF = Direction Flag
Effect of ‘cmp $16, %bx’ • When this compare-instruction is executed the first time (while BX = 0 x 0000), the effect upon the FLAGS value is based on this subtraction: (binary zero) 00000000 (binary 16) - 00000100000 -----------------= 11111100000 • Thus SF=1, ZF=0, CF=1 (due to ‘borrow’), etc.
The ‘jb again’ instruction • This conditional-jump instruction examines the setting of the CF-bit (the Carry-Flag) – If CF=1 (i. e. , true), then control is transferred to backward, to the instruction at ‘again: ’ – If CF=0 (i. e. , false), then control continues forward normally (i. e. , it “falls through” to the instruction that follows the conditional-jump • The CPU performs its ‘jump’ by adding a signed-integer to the value in register IP
Asynchronous interruptions! • So programs can be ‘interrupted’ anytime (i. e. , at the end of any fetch-execute cycle) • Maybe even, for example, right here: cmp $16, %bx jb again An interrupt could occur AFTER the cmp-operation has set the FLAGS, but BEFORE the jb-instruction has tested any of those FLAG-bits
Consider the ‘yes’ case Fetch next instruction Advance instruction-pointer Decode fetched instruction Execute decoded instruction no INTR ? yes Interrupt Service Routine The Interrupt Service Routine may do some arithmetical or logical operations that cause FLAGS to be modified – and so invalidate the program’s conditional-jump!
How CPU solves this problem • When an interrupt-request is recognized by the CPU, it automatically ‘saves’ the crucial elements of its program-context • Thereby it can ‘resume’ its main program (after it services the interrupt) with those crucial register-values restored: – The address of the next instruction (CS: IP) – The previous settings of the FLAGS bits
The ‘interruption’ senario Programmable Interrupt Controller (PIC) INTR INTA Central Processing Unit (CPU) SS SP FLAGS CS IP Dynamic Random Assess Memory (DRAM) interrupt handler stack-area main program peripheral device (keyboard, mouse, timer, etc) Interrupt Vector Table
The sequence of actions 1. 2. 3. 4. 5. 6. Some device issues an interrupt-request Interrupt Controller forwards it to CPU saves FLAGS, CS, and IP on stack CPU issues acknowledgement to PIC sends Interrupt ID-number to CPU uses ID-number as index into IVT and loads CS and IP with vector-values
What the ISR works with • The Interrupt Service Routine begins with the its stack setup like this: Saved FLAGS value Saved CS-value Saved IP-value room here for the stack to grow downward as needed SS: SP (“top” of the stack) If the ISR needs to use any of the other CPU registers, it should push their values onto the stack before it modifies them, then pop those saved values back before returning
What does ‘iret’ do? • An Interrupt Service Routine concludes by executing an ‘iret’ instruction -- to resume whatever program had gotten interrupted, and with its FLAGS restored as they were • So what ‘iret’ does is to ‘pop’ the top three word-values off the stack and into the IP, CS, and FLAGS registers, respectively, in a single ‘atomic’ operation
A role played by the PIC • Before resuming an interrupted program, an interrupt-handler needs to let the PIC know that it has finished servicing the preceding interrupt-request, and that it now is safe to be sent another request • Otherwise the stack-area might grow too large if more and more new interrupts got sent while old ones were being serviced
The EOI command • Here’s how an interrupt-handler sends an ‘End-Of-Interrupt’ notification to the PIC: mov $0 x 20, %al out %al, $0 x 20 # put EOI command-code in AL # output AL to port number 0 x 20 • NOTE: It’s pure coincidence that the same number (i. e. , ‘$0 x 20’) is used twice in this code-fragment (but easy to remember it!)
Our demo-program • To illustrate the PC’s interrupt-handling mechanism, we wrote a short program (named ‘tickdemo. s’) that you can study • It has two ‘threads-of-execution’, plus a ‘shared’ variable that both threads use (i. e. , one as ‘writer’, the other as ‘reader’) • The main thread stores a new value into the IVT that points to the second thread
A timer-tick will interrupt ‘main’ Our program structure ticks: 0 The ‘isr’ thread Interrupt vector table = IVT[ 0 x 08 ] The ‘main’ thread
A ‘critical section’ of code • Modifying the timer-tick interrupt-vector is done by a two-step instruction-sequence – First change the vector’s lo-word (offset) – Then change the vector’s hi-word (segment) • What if an interrupt should occur between those two steps? • We MUST prevent that from happening! • So we use the ‘cli’ and ‘sti’ instructions
In-class exercise • The BIOS startup-code programs the timer so that it issues interrupts at a steady rate of about 18. 2 timer-ticks per second • Can you modify our interrupt-handler code so that it only increment the ‘ticks’ counter once-per-second? i. e. , like a digital watch • HINT: You may need to add at least one new variable in this program’s data-area
An arithmetical ‘hint’ • The number of seconds that have elapsed since ‘ticks’ began counting occurrences of timer-interrupts can be obtained using one of these formulas: # How we can calculate ‘elapsed seconds’ from the value of ‘ticks’ seconds = ticks (ticks-per-second) = ticks 18. 2 = ticks (182 / 10) = ( ticks * 10 ) / 182 use this last one!
- Slides: 22