INTERRUPTS I/O HARDWARE

I/O Systems
The two main jobs of a computer are
I/O [CPU] processing

In many cases, the main job is I/O, and the [CPU] processing is merely incidental. I/O is a major factor in system performance It places heavy demands on the CPU to execute device-driver code and to schedule processes fairly and efficiently as they block and unblock

I/O HARDWARE
Computers operate a grate many kinds of devices (Storage devices, transmission devices, human interface devices etc,.) Device communicates with the computer system by sending signals over a cable or even through the air Port
Connection point that the device communicates with the device

Bus
Common set of wires

Daisy chain
Usually operates as a bus

PC BUS STRUCTURE
PCI bus connects processor-memory subsystem to fast devices Expansion bus slow devices SCSI bus and SCSI controller Controller operate a port, bus or a device

I/O DEVICE CONTROL

Devices controlled via special registers of a device controller CPU needs to control devices
Read or write control signals or data in special registers of a device controller

General interfaces
Port I/O: Special I/O machine instructions that trigger the bus to select the proper I/O port & move the data into or out of a device register
E.g., IN, INS, OUT, OUTS on numerous Intel architectures

Memory mapped I/O: The I/O registers of the device become part of the linear memory space of the RAM of the computer; standard memory load and store machine instructions are used

E.g., a serial port might use port I/O, while a graphics controller could have a memory-mapped image of the computer screen

GENERAL METHODS FOR ACCESSING DEVICES

Two general methods by which devices can be accessed
Each of these methods can be used with either ports or memory-mapped I/O

Polling
A busy wait, repeatedly checking a device for some change in status

Interrupts
Using interrupt line of CPU to provide service to devices

POLLING
Also called programmed I/O CPU is used (e.g., by a device driver), in a program code loop, to continuously check a device to see if it is ready to accept data or commands, or produce output
Continuous polling

In some cases, a process periodically checks a device, and then blocks until next period elapsed
Periodic polling

E.g., a USB mouse might be periodically polled for data at 100 Hz rate Loop (until device ready)
Check device

End-loop

 2 bits are used to coordinate the producer consumer relationship between the controller and the host
Host repeatedly reads the busy bit until that bit becomes clear The host sets the write bit in the command register and writes a byte into the data out register Host sets the command ready bit When command ready bit is set, controller sets busy bit Controller reads the command register and sees the write command. It reads the data out register to get the byte and does the I/O to the device Controller clears the command ready bit.
Error bit I/O suceeded Busy bit finished

ISSUES WITH CONTINUOUS POLLING

CPU is tied up in communication with device until I/O operation is done No other work can be accomplished by CPU Typically one CPU in system, but many I/O devices May be useful if controller and device are fast
Programmed I/O can be more efficient than interrupt-driven I/O, if the number of cycles spent busy-waiting is not excessive

If polling interleaved with other processing

Device may be idle because we dont supply it with information or a new request Device might have a fixed length buffer, and we may get buffer overrun conditions, resulting in data loss

HARDWARE INTERRUPTS
I/O via software continuous polling can be inefficient
CPU may spend too much time waiting for devices
I.e., amount of time between I/O operations may be large

Only one CPU; continuous polling may tie up this resource

Often better to design differently

Handle I/O as different type of event No longer have CPU actively wait until device is ready for next operation Instead, have the device send an asynchronous signal-- an interrupt when it is ready

INTERRUPT DRIVEN I/O CYCLE Step 1

INTERRUPT DRIVEN I/O CYCLE Step 2

INTERRUPT DRIVEN I/O CYCLE Step 3

INTERRUPT DRIVEN I/O CYCLE Step 4

INTERRUPT DRIVEN I/O CYCLE Step 5

INTERRUPT DRIVEN I/O CYCLE Step 6

INTERRUPT DRIVEN I/O CYCLE Step 7

INTERRUPT HANDLING FEATURES

Ability to defer interrupt handling during critical processing An efficient way to dispatch to the proper interrupt handler for a device without first polling all the devices to see which one raised the interrupt We need multilevel interrupts, so that the operating system can distinguish between high and low priority interrupts and can respond with the appropriate degree of urgency

INTERRUPT VECTOR
Contains memory addresses of specialized interrupt handlers Interrupt vector table has a small collection of addresses for particular interrupt handling routines If more devices than interrupt vector addresses, interrupts are chained & short sequential search is done; interrupt handlers called in sequence until one can handle interrupt

Pentium Processor Event-Vector Table

(0 31) non maskable (32 - 255) maskable

OTHER INTERRUPT FEATURES

Interrupts can have different priorities
A higher priority interrupt can interrupt the handler of a lower priority interrupt (but not vice versa)

Maskable vs. nonmaskable interrupts

Normal I/O uses maskable interrupts that can be turned off (e.g., when kernel executes a critical section) Fatal error conditions may use a nonmaskable interrupt to make sure interrupt gets through (e.g., see Fig. 13.4)