CS 471 -- Lecture 2

OS and Hardware Development

OS development has gone hand-in-hand with hardware development:

Interrupts drive data transfer (using multiple CPUs, one designed exclusively for I/O processing)
Direct-memory-access (DMA) data transfer
Hardware memory protection (to validate addresses)
Hardware instruction protection (only "special" users can execute some machine instructions)
Support for other interrupts: clock.

Old days: "busy wait", e.g. printing:

Pseudo-code: check hardware switch (physical memory location which printer can change) to see if printer is ready for next character. if switch not set, go to step 1. send printer next char. if more to print, go to step 1. stop.

(steps 1 and 2 constitute the busy wait.) This same idea works for buffers as well as single characters: processor fills buffer (of maybe 512 characters), then uses busy wait for external device to signal that it has emptied the buffer. Though buffers are going to be more helpful if not using busy wait (why?)

This waste of valuable CPU time (due to speed mismatches between CPU and external devices) is reduced by introduction of hardware interrupts.

Interrupt Handling

     main memory

    addr |  inst
   ------+--------
     100 | br 200    Assume HW supports 16 interrupts
     101 | br 300 
     102 | br 350 
     104 | br 550 
      .     .
      .     .
      .     .
     115 | br 950
      .     .
      .     .
      .     .
      .     .
      .     .
      .     .

HW support: for each interrupt type (e.g. clock interrupt, IO completion, change to supervisor state, invalid instruction) the HW changes to program counter to a "prewired" memory address (in the above example, 100 for interrupt type 0, 101 for interrupt type 1, etc.) This results in the specific code to handle that interrupt being executed.

Examples:

Suppose clock interrupts are "wired" to memory location 100. Then in a typical RR system, the interrupt causes a transfer to code which checks the cause of the timer interrupt. If the cause is that a process has gotten its "time slice" then scheduling code will save the state of the current process, maybe do accounting, pick the next process to execute, restore its state, and start it.
Suppose memory location 102 is associated with the "invalid instruction" interrupt. What then?
Well, for one thing, this allows things the same machine code to be used in machines that don't have quite the same instruction sets (say, across a product line from cheap slow processors to expensive fast processors).
Once the hardware supports this, then I/O can be handled much more efficiently. It is also used for security. If some instructions are privileged, then if a "normal" process attempts to execute them, the OS (through interrupt code) can validate what is happening.

The point has been to do things FAST. So that things are only checked when they need to be. This requires a combination of HW and SW support.

Memory Protection:

Base register: contents of base register are automatically added (by HW) to each address. Not done by SW since this would be too slow.


                    Main Memory
              0   +-------------+
                  |             |   To switch from J1 to J3, OS changes
                  |   OS        |   base register contents of 10000 to
                  |             |   60000.
          10000   +-------------+
                  |             |
                  |   J1        |   This simplifies much system software.
                  |             |   For example, compilers can now "pretend"
          40000   +-------------+   that all code is loaded starting at
                  |   J2        |   addr 0.
                  |             |
          60000   +-------------+
                  |   J3        |
                  |             |
                  |             |
                  |             |
          90000   +-------------+
                  |   J4        |
                  |             |
                  |             |
                  +-------------+
                  |/////////////|
                  |/////////////|
                  +-------------+

Limit register: make sure user does not reference beyond allocation memory size. Load limit register with size of memory allocated to process. HW traps (that is causes an interrupt) if the process attempts to use an address larger than limit register contents.

Note: this is NOT checked in software (much too slow). It must be done in hardware as a side effect of addressing memory SO THAT NOTHING SLOWS MEMORY REFERENCES DOWN. THE SAME GOES FOR THE USE OF THE BASE REGISTER. If memory references are validated, the mechanism must be very fast.

How does the OS get around this? Two basic approaches:
- some machines allow interrupts to be turned off, or
- interrupt handler can check to see who is trying to do memory reference.

Index Previous Next