We have seen how a simple computer system executes a program at register

level. We have discovered the main types of interaction with the main system
memory. We will now look at interactions with I/O devices and interrupt driven
I/O. But first we review the concept of subroutines.

Subroutines
Let’s say that you install an automatic meal preparation device. Which will
prepare a meal for guests. The program for meal preparation is.
- Prepare main meal
- Prepare dessert

You can describe each step in the main program in more detail as
subprograms (subroutines) to prepare the courses. Instead of writing out all the
details from a recipe book you would refer to the appropriate sections. Hence if
you wanted to serve chicken teriyaki instead of chicken fajitas, just refer to the
chicken Teriyaki recipe. Or if you prepare 10 meals instead of 4 meals you just
modify the recipes. The recipes are subroutines that the main meal preparation
program is free to use when required.
A subroutine allows us to reuse code. It is a section of a program that may be
used one or more times. A main program calls subroutines to perform certain
steps. This means that the main program is less cluttered and modifications
are easier to make.
Looking at the CPU MEMORY interaction from another angle, to execute the
instruction "Memory [125] := 0;" the CPU places the value zero on the data bus, the
address 125 on the address bus, and asserts the OE write line (later) on the “control
bus” since the CPU is writing data to memory:

Memory write

To execute the equivalent of "CPU := Memory [125];" the CPU places the address
125 on the address bus, asserts the read line since the CPU is reading data from
memory, and then reads the resulting data from the data bus:
Memory read
 Main 2) Main calls a
call Main JSR Subr2 subroutine which
JSR Subr2 call : in turn calls a
: JSR Subr1 nested subroutine
JSR Subr1

Subr1
call
:
JSR Subr2
:
RTS
Return from call
Subr2
: Subr2
: :
RTS :
Return from call RTS
1) Main calls a subroutine Return from call
In developing our meal preparation device, the Prepare meal
use of subroutines allows us to take a
top-down approach to programming, rather
(main)
than jumping straight into the programming
So let us consider how a meal is made by a
well organised cook. The meal preparation
Prepare course
would roughly go through the following steps.
- Decide what courses
- for each course
- look up recipe
- collect ingredients Look up recipe
- collect kitchen utensils
- follow recipe instructions

Since we are not trainee chefs, we will study Collect ingred.

these steps from the point of view of a
programmer. We could for instance have main :
program that performs the general task :
prepare meal. That program would call a
subroutine called prepare course. The prepare
course subroutine could call further subroutines
to lookup recipe, collect ingredients,..etc
Interrupts
Consider what would happen if you were in the middle of preparing a meal
(peeling potatoes for instance) and the soup boils over. You would have to
interrupt your potato peeling to remove the soup pot from the stove and clean
the mess.

Interrupts on a P.C
Interrupts in a P.C. work in a very similar fashion. An external event causes the
CPU to suspend whatever it is doing. The CPU will finish the instruction it is
currently executing after which it saves the state of the CCR (see later) to the
stack. (This is the CPU equivalent of placing a bookmarker in the recipe book)
To handle the interrupt the CPU jumps to a special subroutine called an
interrupt service routine (ISR). Once it has executed this interrupt service
routine, it unloads its previous state from the stack (finds the bookmark in the
recipe book) and resumes whatever task it was performing. Interrupts can
happen at any time since they are triggered by outside events. Interrupt
service routines are usually assigned a interrupt vector, a fixed address from
which the ISR starts.

Each interrupt routine has an interrupt vector and the CPU is configured to
jump to that address, each time the corresponding interrupt line is activated.
NOTE: An simpler but less efficient alternative to interrupt driven control of
input output devices relies on the concept of polling. This approach, the
CPU periodically suspends its main task to check if an external event has
occurred.

A standard P.C. has input pins for up to 15 different interrupts, some of

which can be connected to peripheral devices such as hard disk, printer,
mouse, modem, video card (which is connected to the computer monitor). 15
interrupt lines might seem like a lot, however, it is often the case that there
are not enough interrupt lines to go around, and some times devices have to
share an interrupt line. This is one of the most common causes of difficulties
when installing new hardware.

IRQ conflict
Lets consider the case where a modem and a network card share the same
interrupt line, and the network card interrupt generates an interrupt to
indicate that new data is arriving from the network. Unless the software for
both devices is sophisticated enough to cope with this problem, the CPU will
not be able to determine whether, the IRQ originated with the network card
or the modem. As a result, the CPU may process the wrong interrupt service
routine and may possible crash the computer. This phenomenon is known
as an IRQ conflict.