Chapter 6.

Input-Output Operations.
Abstract.
In the three previous chapters, no mention whatsoever was made of data exchanges
between the computer and the outside world. It was implicitly assumed that all data were
conveniently stored somewhere in central memory and that all results only needed to be
stored in the same memory. This is obviously a too restricted view: programs must be able
to get data from input interfaces such as keyboards and send results to output interfaces
such as video screens or printers. Moreover, programs must be capable of reading and
writing data stored on peripheral storage devices such as disks. In this chapter the
techniques used to couple peripheral devices to computers will first be discussed and
thereafter the various techniques to transfer data will be explained.
6.1. The input/output interfaces.
ach peripheral device normally has its own clock, which is independent of the clock of
the control unit, because most often the timing of peripheral devices is tributary of specific
constraints resulting from the technology of the peripheral device. xamples of such
constraints are the rotational speed of disks or the scanning frequency of a video screen.
Therefore, input and output devices always have to be coupled with the computer through
an interface which takes care of the timing differences. !ig. ".#. represents the block
diagram of an output interface. In its simplest form, an I$ interface consists in a data
buffer, generally one byte wide, and a synchroni%ation bit.
The processor can write and read the data buffer and the synchroni%ation bit. In many
modern processors access to I$ interfaces is done by means of normal data transfer
instructions, the buffer and the synchroni%ation bit having addresses as if they were part of
the memory &'memory mapped I$() but some other processors have specific instruction
for that purpose.
!or clarity, an output interface is discussed here, but it is quite obvious that an input
interface works exactly in the same way, but in the opposite direction.
*hen a program has to send a string of bytes to an output device, it writes the first byte in
the data buffer. This operation causes automatically the synchroni%ation bit to be set. This
informs the output device that a byte is available in the data buffer. *hen the output
device is ready to handle the byte, it reads it from the data buffer. This read automatically
resets the synchroni%ation bit. +efore writing the second byte in the data buffer the
processor checks whether the first one has already been used by checking the state of the
synchroni%ation bit. This synchroni%ed transfer process continues until the entire string has
been received by the output device.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-#
C
O
M
P
U
T
E
R
I/O
D
E

I
C
E
D
A
T
A
!"
!ig.".#. +lock diagram of an Input-$utput interface.
6.#. Input-output s"nchroni$ation b" po%%in&.
The simplest way of programming I3$ operations consists in testing repeatedly, by
program, the synchroni%ation bit until the next byte can be transferred. !igure ".1 shows
how an I3$ interface is integrated in a computer to allow writing in the 6ata buffer and
reading the state of the /y bit.
Table ".# gives the text of a Modula 1 procedure which can be called repeatedly to send a
string of characters to an I3$ device such as a printer.
PROCEDURE Print (C:CHAR);
VAR
Data [0FFC0H] : CHAR; (* Interface data buffer *)
Sy [0FFC1H] : !!"#A$;(* %R&# '(en c(ar) in buffer *)
BEGIN
REPEAT UNTIL $!% Sy;
Data :* C;
Sy :* %R&#
END Print;
Table ".#. 0rint procedure using polling.
The hexadecimal numbers between square brackets in the variable declarations impose the
compiler to assign specific addresses to these variables. These addresses are the hardware
defined addresses of the data buffer and the synchroni%ation bit.
The polling is done by the 708T 9:TI; loop, which doesn<t do anything else than
testing the synchroni%ation bit at each iteration.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-1
I/O
D
E

I
C
E
D
A
T
A
!"
CPU
'e'
Computer bus
I/O interface
!ig.".1. I3$ interface connected for polling.
0olling is by far the simplest way of synchroni%ing I$ operations, but while the program is
in the 708T loop, no other useful work is being done by the processor. *hen one
reali%es that typical timings for slow I$ devices such as printers and keyboards are in the
order of tens to hundreds of milliseconds while .09 timings are usually expressed in tens
of nanoseconds, it becomes clear that polling is only acceptable in systems, where no other
tasks can be assigned to a waiting processor.
6.(. Interrupts.
Interrupts allow to temporarily, or definitively, suspend the active program to execute
another task. It is an hardware signal which causes the processor, upon completion of an
instruction, to fetch the next instruction at a specific address defined in con=unction with
the interrupt rather than at the address resulting from the normal program execution. The
interrupt mechanism is used to reset the processor after a power down, and, in normal
operation, to switch the processor between different tasks.
0roviding interrupts in a computer requires adequate answers to two essential questions:
- how is defined the address where an instruction has to be fetched after an interrupt>
- how is saved the state of the interrupted program in order to allow resuming the
execution after handling the interrupt >
8nswers to both questions will be discussed in the next sections.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-?
".?.#. The address of the interrupt handler.
Most processors recogni%e many hardware generated interrupts. *ith each interrupt a
specific begin address for the handler should be associated.
8 common way of making this association consists in defining a priori, by hardware, the
address associated with each interrupt line. xamples of this approach are to be found in
the I:T; @4@" family of processors, which have eight distinct interrupt lines, numbered
from 4 to A, each associated with an address which is equal to the interrupt number
multiplied by 5. This way, for each interrupt line, the programmer has 5 bytes to store a
=ump to the actual interrupt handler.
The technique used in the Motorola "@444 family is slightly more sophisticated: instead of
fetching an instruction at an address associated with each interrupt line, the Motorola
processors fetch the address of the instruction to be fetched at memory locations
associated with each interrupt line.
8nother approach to finding the appropriate interrupt handler consists in requiring the
device which caused the interrupt &in general an I$ interface) to provide itself the address
of the interrupt handler. In fact, in such systems, when an interrupt has occurred, the
control unit starts a fetch cycle without giving a read command to the memory. Instead it
gives an 'interrupt acknowledge( signal to the device which caused the interrupt, and
which is then responsible for putting on the data bus a control instruction that will transfer
control to the interrupt handler. This last technique is often called 'vectori%ed interrupt(
and has been introduced by 6igital quipment, with the 060## series of minicomputers in
the early seventies. It is ideal for modular computer systems to which the users can add a
large number of their own interfaces.
".?.1. /aving the state of the interrupted process.
In some respect there is an analogy between a subroutine and an interrupt handler, as in
both cases, after completion, control must be returned to a previously active program.
Therefore activating an interrupt handler is often implemented as the execution of a 'call
subroutine( instruction, which saves the return address on the stack. The end of the
interrupt handler could then =ust consist in a 'return( instruction.
There is, however, a ma=or difference: a programmer knows where a 'call subroutine(
instruction is written while there is no way to know when an interrupt will occur. 8s an
interrupt handler is likely to use some processor registers, the contents of all these
registers should be saved before they are used and restored before control is returned to
the interrupted program.
In some processors only the return address and the contents of the condition code register
are saved and restored automatically, so that the programmer must save and restore
explicitly all other registers which might be modified by the interrupt handler. In other
processors all the registers are automatically saved on the stack and restored. The later
approach is, of course, more convenient for the programmer, but causes significant delays
in answering an interrupt, which could be a waste when only very few registers are used
by the interrupt handler.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-5
8 last system, which is particularly efficient for small but fast systems consists in having in
the processor two complete sets of registers, such that, at any moment only one set is
accessible. *hen an interrupt occurs, the two sets are automatically switched and at the
return from the interrupt handler the two set are switched back. The ma=or drawback of
this approach is that an interrupt handler can never be interrupted itself, as that would ruin
the state of the initially interrupted program. Inhibiting other interrupts during handling of
an interrupt is possible, but could cause unacceptable delays in answering some interrupts.
".?.?. Interrupts and I$ operations.
*riting the procedures controlling I$ operations as interrupt handlers, and allowing the
I$ interfaces to generate an interrupt each time the synchroni%ation bit is reset by the
peripheral device solves the problem of the inefficient 'busy waiting( associated with
polling. It however slows down the attainable transfer speeds, as for each byte to be
transferred to or from the I$ interface, the state of an interrupted program must be saved
and restored. !igure ".? shows schematically the computer with an I$ interface with
interrupt capability.
I/O
D
E

I
C
E
D
A
T
A
!"
CPU
'e'
Computer bus
I/O interface
interrupt
!ig.".?. I3$ interface with interrupt capability.
/pecific interrupt handlers associated with I$ interfaces are often called 'I$ drivers(.
They not only handle the interrupts generated by the interface but also manage the
operation of the peripheral device by converting the data representations used by the
program into those used by the peripheral device and by interpreting errors messages such
as 'printer out of paper(. 6rivers for peripheral devices are, in general, specific for that
device and are provided together with the device by the manufacturer.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-B
Modula 1 allows writing one<s own interrupt handlers by using the 07$.// concepts
available in that language. 8n example of such a printer driver is shown in tables ".1. to
".B.
DEFINITION MODULE Printer;
EXPORT QUALIFIED Print;
PROCEDURE Print(c( : CHAR);
END Printer)
Tab. ".1. 0rinter module: 6efinition module.
IMPLEMENTATION MODULE Printer[+]; &C module priority D 5 C)
FROM S,S%#- IMPORT .!RD/ ADR/ SI0#/
PR!C#SS/ $#.PR!C#SS
%RA$SF#R/ I!%RA$SF#R/ "IS%#$;
CONST ufSi1e * 20;
VAR
uffer : ARRAY[1))ufSi1e] OF CHAR;
uf$u3 : I$%#4#R; &C :umber of .haracters in +ufferC)
in/5ut : [1))ufSi1e] &C *rite and read pointers for +uffer C)
6ut/7et: PROCESS &C 0roducer and consumer processes for +uffer C)
'86 : ARRAY[1))100] OF .!RD; &C process workspace C)
Data [0FFC0H] : CHAR; &C printer interface data buffer C)
Sy [0FFC1H] : !!"#A$; &C printer interface synch. bit C)
&C 07$.697 0rint: /ee table ".5 C)
&C 07$.697 6river: /ee table ".B C)
BEGIN
uf$u3 :* 0; in :* 1; 5ut :* 1; &C +uffer initiali%ation C)
$#.PR!C#SS(Dri9er/ ADR('86)/ SI0#('86)/ 7et);
&C 8llow the procedure 6river to behave like an interrupt handler C)
%RA$SF#R(6ut/7et);
&C and activate it a first time C)
END Printer)
Table ".?. 0rinter Module: data declarations and initiali%ations.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-"
PROCEDURE Print(c( : CHAR);
&C put one character in driver buffer, wait if buffer is full C)
BEGIN
I$C(uf$u3); &C increment char. count in buffer C)
WHILE (uf$u3 : ufSi1e) DO &C *hile buffer is full C)
END; (* .HI"# *) &C wait for driver to remove characters C)
uffer[in] :* c(; &C put character in +uffer C)
in :* (in MOD ufSi1e) ; 1; &C and update write pointer C)
IF (uf$u3 * 0) THEN &C *as buffer empty before this > C)
%RA$SF#R(6ut/7et) &C Ees, - /tart driver C)
END; (* IF *)
END Print;
Table ".5. 0rinter module: 0rint procedure.
PROCEDURE Dri9er;
&C sends, one by one, characters from +uffer to the printer interface C)
BEGIN
LOOP &C once started, an interrupt handler remains in an infinite loop C)
D#C(uf$u3); &C decrement char.count in buffer C)
IF (uf$u3 < 0) THEN &C if buffer was empty, the producer C)
%RA$SF#R(7et/6ut); &C rather than the consumer is needed C)
END; (* IF *)
Data :* buffer[5ut]; &C send one character to interface C)
5ut :* (5ut MOD ufSi1e);1; &C and update read pointer C)
Sy :* %R&#; &C activate interface C)
I!%RA$SF#R(7et/6ut/=H); &C suspend driver until interrupt ? C)
Sy :* FA"S#; &C deactivate interface C)
END (* "!!P *)
#$D Dri9er)
Table ".B. 0rinter module: 6river procedure.
This printer module creates, next to the program which uses the printer driver, an
additional program, an interrupt handler, which runs concurrently and loads, one by one,
in response to interrupts generated by the printer interface, the characters to be printed in
the data register of the interface. These two programs are respectively identified by the
scheduler of the operating system by the names put and get. .haracters are transferred
between them through the array +uffer.
To use the printer module, a program has to import the Prit procedure, which puts
characters to be printed in the buffer. *hen the buffer is full, the procedure Prit waits
in a loop until the printer driver has removed a character from the buffer.
The interrupt handler, materiali%ed by the procedure Dri!er, is written as an infinite
loop. Inside this loop, the IOTRANSFER instruction suspends the driver, returning control
to the program which was active before an interrupt activated the driver. *hen an
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-A
interrupt occurs, the driver restarts at the instruction following the IOTRANSFER
statement.
The T78:/!7 statement is used to instruct the scheduler to deactivate one program
and activate another one without waiting for an interrupt.
Additional details about the implementation of such interrupt handlers will be explained
in more detail in chapter 10, where the concept of concurrent processes will be
introduced.
6.). Direct Me'or" Access.
The programmed I$ techniques, as described in sections ".1. and ".? are adequate for
slow peripheral devices such as keyboards and printers but are much too slow for faster
devices such as disks. Indeed, the simplest I$ procedure, transferring a block of bytes
from memory to a disk interface, such as the one shown in table ".x#, requires at least the
execution of #4 machine instructions per transferred byte. 8dmitting that the processor
can execute #4 instructions per microsecond, the transfert speed could not exceed #
Mbytes per second, which is clearly insufficient for modern disks.
PROCEDURE Di8>%ran8fert(VAR A : ARRA, !F yte);
VAR
Data [0FFC0H] : CHAR;
Sy [0FFC1H] : !!"#A$;
i : CARDI$A";
BEGIN
FOR i :* 0 TO HI4H(A) DO
REPEAT UNTIL Sy;
Data :* A[i]
END
END Di8>tran8fert
Table ".x#. /implest possible procedure to write on a disk.
The low speed of programmed I$ operations is, in fact, a result of the versatility of a
.09: this device is so universal, that to be instructed to move one byte from one address
to another and to keep track of the number of bytes already moved, it needs to fetch over
thirty bytes from memory to its control unit. To avoid all this time consuming overhead,
most computers have an additional processor, much simpler than the .09, which can
perform only one task, move bytes from one location to another. 8s this device, called a
'Direct Memory Access Controller( performs always the same task, it doesn<t need to
fetch any instructions, and can therefore do data transferts at much higher speeds than the
.09.
!igure ".? shows a typical computer system with direct memory access. The 6M8. has
three registers which can be accessed by the processor and which respectively contain the
origin address, the destination address and the number of bytes to be transferred. The
6M8. has one 'ready( input, similar to the interrupt input of the processor, enabling the
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-@
transfert of one byte, connected to the synchroni%ation bit of the I$ interface and one
output, signaling the completion of a block transfert, to be connected to an interrupt line
of the processor.
I/O
D
E

I
C
E
D
A
T
A
!"
CPU
'e'
Computer bus
I/O interface
ready
DMAC
bus request/
bus granted
interrupt
!ig.".?. I$ interface with 6M8..
*hen a block of data has to be transferred, an I$ driver, running on the .09, initiali%es
the registers of the 6M8.. $nce initiali%ed, the 6M8. performs the transfert and
informs the driver of the completion of the task by generating an interrupt. In fact, a
6M8. divides the frequency of interrupts by the si%e of the blocks of data.
8s both the processor and the 6M8. can access central memory and I$ interfaces
through the bus, conflicts can arise. To avoid such conflicts, the 6M8. can, through
special '+us 7equest( and '+us Franted( lines, request the control unit of the .09 to
temporarily suspend all activities and leave the bus alone. *hen the interface buffer is free,
the 6M8. requests the bus. 8s soon as the current memory cycle is completed, the
control unit free%es the processor, releases the bus and informs the 6M8. through the
+8F line. The 6M8. then transfers a byte and returns the bus to the .09 by resetting
the +7 line. The way the 6M8. operates is sometimes called 'memory cycles stealing(.
It makes accurate prediction of the duration of program execution difficult.
6.*. A+,ance+ IO s"ste's.
In all modern computers I$ operations are performed through I$ interfaces and 6M8
controllers, but these interfaces and controllers can be much more sophisticated than those
described in the previous sections.
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-2
Most I$ interfaces, instead of a single data register, have a !irst In !irst $ut buffer,
allowing many bytes to be loaded consecutively into the interface. The synchroni%ation bit
is then replaced by a mechanism keeping track of the number of bytes present in the !I!$
queue, inhibiting fetches when the queue is empty and loads when it is full and generating
interrupts or 6M8. requests when data should be transferred to or from central memory.
:ext to the !I!$ management, additional status bits allow the driver to be informed of
particular conditions in the peripheral device, such as a printer out of paper or an attempt
to write on a write protected disk. These status bits can cause specific interrupts which are
directly interpreted by the I$ driver.
6irect Memory 8ccess .ontrol also can be much more sophisticated: for example, many
controllers can be programmed to transfer data to interfaces with !I!$ buffers by bursts in
consecutive memory cycles rather than one byte at a time and, rather than having to be
reinitiali%ed for each data block, they can be programmed to execute consecutively several
block transfers.
/ophisticated I$ interfaces combined with 6M8<s can become fairly complex devices,
almost as complex as central processors. They are then called I$ channels or I$
processors.
6.6. References.
7obert M.Fraham
0rinciples of systems programming
,ohn *iley G /ons, #2AB
I/+: 4-5A#-?1#44-#
dward ,.,oyce
Modula-1
8ddison-*esley, #2@B.
I/+: 4-14#-##B@A-B
7.Haks,
!rom chips to systems
/ybex, #2@#.
I/+: 4-@2B-@@4"?-"
,.Tiberghien - .omputer /ystems - 0rinted: 12342314#5
.hapter "-#4