EE206: Software Engineering IV 1.

6 Input/Output page 1 of 9

Section I
Section Real Time Systems. Processes

1.6 Input/Output Management

(Textbook: A. S. Tanenbaum “Modern OS” - ch. 5)

• Input/Output Overview

• Input and Output operations allow the process to

interact with the outside world.

Process

I/O IPC
Outside Other
world processes

• Usually this involves data exchange between:

• CPU and memory

and
• Diverse I/O devices (keyboard, mouse, disk
drives, video card, network card, etc.)

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 2 of 9

• These I/O devices allow:

• to get input
• to produce output
• to store information

• I/O management is complicated:

• Must issue commands to the devices, catch

interrupts, and handle errors.
• Must provide the same interface (device
independence) between the devices and the
rest of the system which should also be simple
and easy to use

• I/O Device Classification

1. Block devices

• Store information in fixed-size blocks.

• Each block has its address.
• Common block sizes: 128 bytes to 1K bytes.
• Each block could be read or written
independently of the other ones (i.e. random
access).
• E.g.: Disks.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 3 of 9

2. Character devices

• Delivers or accepts a stream of characters,

without regard to any block structure.
• It is not addressable.
• Does not have any seek operation (i.e. no
random access).
• Most devices that are not disk-like can be seen
as character devices.
• E.g.: Printer, terminal, plotter, network
interfaces, tape.

3. Other devices

• Some devices are neither character nor block

type.
• E.g.: Clocks (cause interrupts at well-defined
intervals).

Note:

• Although not perfect, the model of block and

character devices is usually enough.
• It can be used as a basis for making some of
the operating system software dealing with I/O
device independent.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 4 of 9

• I/O Hardware Architecture

• I/O units typically consist of:

• a mechanical component (the device itself)

and
• an electronic component (device controller or
adapter).

• Controllers can handle multiple identical devices,

(e.g. floppy disk controllers usually handles two
floppy disks)

• Operating system nearly always deals with the

controller, not with the device.

CPU MEM

SYSTEM
BUS

FLOPPY HARD TTY CLOCK "CONTROLLER"

DISK

A
KEYB CRT

B X

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 5 of 9

• Nearly all micro- and minicomputers use the

single bus model above for communication
between the CPU and the controllers.

• Large mainframes often use a different model,

with multiple buses and specialised I/O
computers called I/O channels taking some of the
load off the main CPU.

• Controller/CPU Interface

1. A “dumb” controller with no internal buffer

causes an interrupt every time it gets a byte (or a
word) from the device (e.g. disk), to tell the CPU to
fetch it.

CPU CONTROLLER

interrupt
(time critical)

• This kind of interface is time critical.

• Once a disk transfer has started, the bits may

arrive from the device at a constant rate, whether
the controller is ready for them or not.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 6 of 9

• For each byte (word) transferred the CPU would

have to be interrupted and system bus acquired.

• If the CPU or the system bus were busy (e.g.

interrupts temporally disabled by a system
process, or the bus busy due to some other
device using it) the controller would have to wait.

• If the next byte (word) arrived before the previous

one had been transferred, this would cause a
problem, because it has no place to store it.
Overwriting the previous one before it had been
transferred means loss of data.

• In reality a controller has an internal buffer to store

the bytes (words), thus avoiding the time critical
problem.

2. A programmed CPU loop allows read the bytes

one at a time from the controller's buffer.

CPU CONTROLLER

address/
data

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 7 of 9

• The CPU gives the controller the address of the

block and then does other things.

• The controller reads the block from the drive

serially, bit by bit, until the entire block is in the
controller's internal buffer.

• Next, the controller computes the checksum to

verify that no read errors have occurred and if so it
causes an interrupt.

• The CPU can then read the block from the

controller's buffer by executing a loop, with each
iteration reading a byte (or a word) from the
controller and storing it in memory.

• It wastes CPU time!

3. DMA (Direct Memory Access)

• Previously the CPU read the bytes (words) one at

a time from the controller.

• DMA was invented to free the CPU from this low-

level work.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 8 of 9

• DMA is a technique for data transfer which

provides a directed path between the I/O
device and the memory without CPU
intervention.

• With this path, a peripheral device has "Direct

Memory Access" and can transfer data directly to
or from the memory.

• When it is used, the CPU gives the controller two

items of information, in addition to the address of
the block:

• Memory address where the block comes from

or goes to.
• Number of bytes to transfer.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004

EE206: Software Engineering IV 1.6 Input/Output page 9 of 9

• After the controller has read the entire block from

the device into its buffer and verified the
checksum, it copies the first byte or word into the
main memory at the address specified by the
DMA memory address.

• Then it increments the DMA address and

decrements the DMA count by the number of
bytes just transferred.

• This process is repeated until the DMA count

becomes zero, at which time the controller causes
an interrupt indicating that the transfer has ended.

• The CPU does not have to copy the block to

memory: the controller supervised its copy.

• When the block is buffered internally, the bus is

not needed until the DMA begins, so the design of
the controller is much simpler (compare with DMA
without internal buffering) because the DMA
transfer to memory is not time critical.

• Many controllers, especially those for block

devices, support DMA.

C:\Gabi\EE206\2003-2004\worddocs\106_Input_Output.doc Last saved by Gabriel Muntean 06/04/2004