V22.0436.001   Gottlieb    Weds. 12/20      WWH 109
                           2:00-3:50pm

Last year's final exam is on the course home page.

End of Notes

8.5: Interfacing I/O Devices

Giving commands to I/O Devices

This is really an OS issue. Must write/read to/from device registers, i.e. must communicate commands to the controller. Note that a controller normally contains a microprocessor, but when we say the processor, we mean the central processor not the one on the controller.

• The controler has a few registers that can be read and/or written by the processor, similar to how the processor reads and writes memory. These registers are also read and written by the controller.
• Nearly every controler contains
  • A data register, which is readable (by the processor) for an input device (e.g., a simple keyboard), writable for an output device (e.g., a simple printer), and both readable and writable for input/output devices (e.g., disks).
  • A control register for giving commands to the device.
  • A readable status register for reporting errors and announcing when the device is ready for the next action (e.g., for a keyboard telling when the data register is valid, and for a printer telling when the character to be printed has be successfully retrieved from the data register). Remember the communication protocol we studied where ack was used.
• Many controllers have more registers

Communicating with the Processor

Should we check periodically or be told when there is something to do? Better yet can we get someone else to do it since we are not needed for the job?

• We get mail at home once a day.
• At some business offices mail arrives a few times per day.
• No problem checking once an hour for mail.
• If email wasn't buffered, you would have to check several times per minute (second?, milisecond?).
• Checking email this often is too much of a burden and most of the time when you check you find there is none so the check was wasted.

Polling

Processor continually checks the device status to see if action is required.

• Like the mail example above.
• For a general purpose OS, one needs a timer to tell the processor it is time to check (OS issue).
• For an embedded system (microwave) make the checking part of the main control loop, which is guaranteed to be executed at a minimum frequency (application software issue).
• For a keyboard or mouse, which have very low data rates, the system can afford to have the main CPU check. We do an example just below.
• It is a little better for slave-like output devices such as a simple printer. Then the processor only has to poll after a request has been made until the request has been satisfied.

Do on the board the example on pages 676-677

• Cost of a poll is 400 clocks.
• CPU is 500MHz.
• How much of the CPU is needed to poll
  1. A mouse that requires 30 polls per sec?
  2. A floppy that sends 2 bytes at a time and achieves 50KB/sec?
  3. A hard disk that sends 16 bytes at a time and achieves 4MB/sec?
  
  
• For the mouse, we use 12,000 clock cycles each second sec for polling. The CPU runs at 500*10^6 cycles/sec. So polling the mouse requires 12/500*10^-3 = 2.4*10^-5 of the CPU. A very small penalty.
  
  
• The floppy delivers 25,000 (two byte) data packets per second so we must poll at that rate not to miss one. CPU cycles needed each second is (400)(25,000)=10^7. This represents 10^7 / 500*10^6 = 2% of the CPU
  
  
• To keep up with the disk requires 250K polls/sec or 10^8 clock cycles or 20% of the CPU.
  
  
• The system need not poll the floppy and disk until the CPU had issues a request. But then it must keep polling until the request is satisfied.

Interrupt driven I/O

Processor is told by the device when to look. The processor is interrupted by the device.

• Dedicated lines (i.e. wires) on the bus are assigned for interrupts.
  
  
• When a device wants to send an interrupt it asserts the corresponding line.
  
  
• The processor checks for interrupts after each instruction. This requires ``zero time'' as it is done in parallel with the instruction execution.
  
  
• If an interrupt is pending (i.e., if a line is asserted) the processor (this is mostly an OS issue, covered in 202).
  1. Saves the PC and perhaps some registers.
  2. Switches to kernel (i.e., privileged) mode.
  3. Jumps to a location specified in the hardware (the interrupt handler.
  At this point the OS takes over.
  
  
• What if we have several different devices and want to do different things depending on what caused the interrupt?
  
  
• Use vectored interrupts.
  • Instead of jumping to a single fixed location, the system defines a set of locations.
  • The system might have several interrupt lines. If line 1 is asserted, jump to location 100, if line 2 is aserted jump to location 200, etc.
  • Alternatively, the system could have just one line and have the device send the address to jump to.
  
  
• There are other issues with interrupts that are taught in OS. For example, what happens if an interrupt occurs while an interrupt is being processed. For another example, what if one interrupt is more important than another. These are OS issues and are not covered in this course.
  
  
• The time for processing an interrupt is typically longer than the type for a poll. But interrupts are not generated when the device is idle, a big advantage.

Do on the board the example on pages 681-682.

• Same hard disk and processor as above.
• Cost of servicing an interrrupt is 500 cycles.
• The disk is active only 5% of the time.
• What percent of the processor would be used to service the interrupts?
  
  
• Cycles/sec needed for processing interrupts while the disk is active is 125 million.
• This represents 25% of the processor cycles available.
• But the true cost is only 1.25%, since the disk is active only 5% of the time.
• Note that the disk is not active (i.e., actively generating interrupts) right after the request is made. During the seek and rotational latency, interrupts are not generated. Only during the transfer are interrupts generated.