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 I/O device I/O device I/O device I/O device system bus 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 INTR ? Fetch next instruction Advance instruction-pointer Decode fetched instruction Execute decoded instruction no Interrupt Service Routine yes

Compare-and-branch We make frequent use of program-loops, such as this one: xor%bx, %bx# initialize array-index again: … # … inc%bx# increment array-index cmp$16, %bx# index still below 16? jbagain# 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 OFOF DFDF IFIF TFTF SFSF ZFZF 0 AFAF 0 PFPF 1 CFCF Legend:ZF = Zero Flag SF = Sign Flag CF = Carry Flag PF = Parity Flag TF = Trap Flag OF = Overflow Flag IF = Interrupt Flag AF = Auxiliary FlagDF = Direction Flag Status-flags Control-flags

Effect of ‘cmp $16, %bx’ When this compare-instruction is executed the first time (while BX = 0x0000), the effect upon the FLAGS value is based on this subtraction: (binary zero) (binary 16) = 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 INTR ? Fetch next instruction Advance instruction-pointer Decode fetched instruction Execute decoded instruction no Interrupt Service Routine yes 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 Dynamic Random Assess Memory (DRAM) Central Processing Unit (CPU) Programmable Interrupt Controller (PIC) peripheral device (keyboard, mouse, timer, etc) Interrupt Vector Table stack-area main program interrupt handler CSIP SSSP FLAGS INTR INTA

The sequence of actions 1.Some device issues an interrupt-request 2.Interrupt Controller forwards it to CPU 3.CPU saves FLAGS, CS, and IP on stack 4.CPU issues acknowledgement to PIC 5.PIC sends Interrupt ID-number to CPU 6.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: NOTE: It’s pure coincidence that the same number (i.e., ‘$0x20’) is used twice in this code-fragment (but easy to remember it!) mov $0x20, %al# put EOI command-code in AL out %al, $0x20# output AL to port number 0x20

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’ The ‘isr’ thread The ‘main’ thread 0 Our program structure ticks: Interrupt vector table = IVT[ 0x08 ]

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!