- Thus far, we have seen that:
- When program P1 performs an IO operation
that causes the program to become not ready,
the OS stops the program by saving its context in the
corresponding PCB structure variable, removes the program
from the Ready Queue, puts it in the DMA device queue and
then resume with another ready program
- The program P1 that has requested an IO transfer operation
will remain not ready as long as the IO transfer is
But as soon as the DMA has completed the IO transfer operation,
the program P1 is again ready (because it can then
continue with its execution without causing any errors).
Therefore, as soon as the DMA has completed the IO transfer operation,
the PCB of program P1 (which can be found in the DMA queue),
must be removed from the DMA queue and insert back into
the Ready Queue (so that it can (re)claim the use of the CPU).
- The question is how can the CPU tell if the DMA is done with
the transfer operation....
Well, one simple solution is to have the CPU read the status
register of the DMA from time to time to see if the DMA has
But this apporach is inferior to the commonly used solution
that uses interrupt signals
- An interrupt is a special signal on the control bus
that is used by IO devices (DMA) to request the attention
of the CPU:
- The instruction execution cycle (see CS255 class note:
has in fact one more phase !
The complete instruction execution cycle is as follows:
- Fetch (assembler) instruction from memory at address PC and
increment PC (to point to the next instruction)
- Decode instruction fetched.
- Fetch operands needed to execute the instruction
- Execute the instruction
- Check for interrupt signal(s)
- When the CPU detects
that the interrupt signal is
raised (i.e., some IO device is sending an interrupt request),
then the CPU will make a
(unprogrammed) subroutine call
to a location in memory given by a special
Interrupt Base Register (IBR).
- I will first present a simplified version
of how the CPU processes an interrupt
signal (because giving the full details of the operation of
vector interrupts may make you miss the main issue at hand):
- I will assume that there is only one IO device
(controled by 1 DMA).
- The Interrupt Base Register IBR
contains the starting of a routine and from the
description above, the CPU will make a
(unprogrammed) subroutine call to this routine when
the DMA raises the interrupt.
- To give you an idea what it "feels" like to have a program
make "unprogrammed subroutine calls",
I have created the
following C program that prints "." repeatedly in a while loop:
Compile it with:
and run it using:
The main program loop looks like this:
for (i = 0; i < 999999; i++); // Slows the program down a bit...
putchar('.'); // Print "."
fflush(stdout); // Make sure the character is displayed
If you run the program, it will print:
and so on....
You can force
this program to make a
"unprogrammed" function call
to the function
Int_Handler by typing Control-C !!!
It will print the text:
Hello, I'm your firendly interrupt handler. Times called: 0
and then return to the while loop and continue to print ".".
You can force it to call Int_Handler over and over again,
but typeing Control-C.
- Let us get back to the IO communication problem, part II:
how to reclaim the CPU when the IO operation finishes.
Recall the situation prior to the completion of the IO operation:
Make sure you understand what you want to achieve:
- The IO transfer initialized by Program
P1 has completed.
- So program P1 has become ready
- We need to move program P1's
PCB (process control block)
back to the
so program P1 can
(by making the
execute instructions of
- We achieve this as follows:
Recall that in
the CPU will make an
"unprogrammed" subroutine call
to the memory location given by the
IBR (Interrupt Base Register)
detects an interrupt signal.
The following picture depicts the "reclaim the CPU" solution:
While program P3 was running on the CPU (i.e., CPU fetches and executes
instructions from program P3), the DMA completes the data transfer operation.
When the DMA finishes the IO transfer, it will raise the interrupt
The sequence of events that follows is:
Therefore, program P1 has reclaimed the use of the CPU - exactly when
the DMA finishes the IO operation on behave of program P1.
- A subroutine that is
called (= run)
in response to
an interrupt signal is called
a interrupt handler
- Example Interrupt Setup in Assembler:
(Demo above code)
How to run the program:
- use m68000
- There is an
infinite loop in the
- Technically, the
never go somewhere else
- But it does jump to
a number of steps !!!