Chapter 14 -- Exception Handling


The trouble with programmed I/O is that it both wastes CPU
resources and it has potential for "incorrect" operation.

What we really want:
  (Since most I/O devices are slow), have I/O devices signal
  the CPU when they have a change in status.

  The I/O devices tell the CPU that they are "ready."

In order to do this we need:
  Hardware (wires) from devices to the CPU.
  A way for special software to be invoked when the a device
  signals on the wire.

The modern solution bundles the software to deal with
these signals (interrupts) and other situations  into
an EXCEPTION HANDLER.  (Effectively part of the OS.)

 1.  interrupts
     --initiated outside the instruction stream
     --arrive asynchronously (at no specific time)

       I/O device status change
       I/O device error condition
       thermal override shutdown
       internal error detection

     when should the interrupt be dealt with?
       as soon as possible

 2.  traps
     --occur due to something in instruction stream
     --arrive synchronously (while instruction is executing)
         good test:  if program was re-run, the trap would
	 occur in precisely the same place in the code.

       bad opcode
       arithmetic overflow
       I/O functionality, like put_ch
       attempt to access privileged or unavailable memory

     when should the trap be dealt with?
       right now!  The user program cannot continue until
       whatever caused the trap is dealt with.

exception handling

the mechanism for dealing with exceptions is simple; its
implementation can get complex.  The implementation varies
among computers (manufactures).

  situation:  a user program is running (executing), and
	      a device generates an interrupt request.
  mechanism to respond:
	      the hardware temporarily "suspends" the user
	      program, and instead runs code called
	      an EXCEPTION HANDLER.  After the handler
	      is finished doing whatever it needs to,
	      the hardware returns control to the user program.

  limitations of exception handler:
     since it is being invoked (potentially) in the middle
     of a user program, the handler must take extra care
     not to change the state of the user program.
       -- it can't change register values
       -- it can't change the stack
     So, how can it do anything at all?
       The key to this answer is that any portion of the
       state that it wants to change, it must save the
       state and also restore it before returning to the
       user program.

       The handler often uses a stack to temporarily
       store register values.

WHEN to handle an interrupt -- 2 possiblilities:
  1.  right now!  Note that this could be in the middle of
      an instruction.  In order to do this, the hardware
      must be able to know where the instruction is in
      its execution and be able to "take up where it left off"

      This is very difficult to do.
      But, it has been done in simpler forms on a few machines.
      Example:  IBM 360 arbitrary memory to memory copy

  2.  wait until the currently executing instruction finishes,
      then handle.  THIS IS THE METHOD OF CHOICE.

      The instruction fetch/execute cycle must be expanded to

       1. handle pending interrupts
       2. instruction fetch
       3. PC update
       4. decode
       5. get operand(s)
       6. operation
       7. store result

some terms

interrupt request -- the activation of hardware somewhere that
		     signals the initial request for an interrupt.
pending interrupt --  an interrupt that hasn't been handled yet,
		      but needs to be
kernel-- the exception handler
         In most minds, when people think of a kernel, they think
	 of critical portions of an operating system.  The exception
	 handler IS a critical portion of an operating system!
handler --  the code of the exception handler.

Pentium exception handling mechanism

hardware does the following:
 1. signals an interrupt
    on the external pins of the chip, comes a signal that
    means an interrupt request has come in.  Or, placed on
    the pins by the circuitry from within the chip,
    comes a signal that means an trap has come.

    With that signal comes a vector.
    A vector is an encoded value that categorizes the type
    of exception.

    examples:  vector
		 0   divide by zero (a trap, really)
		 2   non-maskable interrupt
		 4   overflow (a trap, really)
		 6   invalid opcode (how could we get one of these?)
		 7   device not available
	there can be up to 256 unique vectors

 2. Uses the vector to get at the code for the exception handler.

    The vector is used as an array index.  The array element
    desired is a Descriptor for the exception handler code.

    a Descriptor:  (Intel calls this a "gate".)

       segment selector         offset bits 15..0

       offset bits 31..16     P  DBL  0111 I/T   000   reserved

       P -- whether the exception handler is in memory or not

       I/T --  distinguishes between trap and interrupt
	       (1 for trap, 0 for interrupt)

       DBL -- 

       segment selector -- an index into yet another array.  This
	     array element will contain a base address within memory
	     to the segment where the exception handler code is.

       offset bits 31..0 -- offset from base address to location
	     of the exception handler code.

 3.  Save current program's state.

     This stuff logically belongs on a stack.  Intel (like many
     other machines) has several stacks.  There is one set
     aside just for use when an exception occurs.

     Yet another table keeps the values of the stack pointers
     within the stacks.

     The stack for exceptions will have (after saving state)

       |              |
       |    PC (EIP)  |
       |      |  CS   |
       |    EFLAGS    |
       |     ESP      |
       |      |  SS   |
       |              |

       Note that we now have saved away the return address for
       when the exception handling is finished.

Then, the code within the exception handler is run.
It does whatever it needed to do.

When the exception has been handled, it is time to restore
the state of the previously running code, and then go back
to executing that code.

What has been done by the hardware (saving state, setting
new values for registers), must be undone by the hardware!
On this architecture, this is accomplished by a single
instruction called iret.
   iret pops stuff off the stack (the one for exception handlers),
   and puts the stuff back in the right place.
     The PC is restored.
     The EFLAGS register is restored.
     The previous value of ESP is restored.


some advanced topics


The operating system (OS) needs to be able to control access
to ALL computer system resources.

  Some resources:
    the processor  (for executing code!)
    main memory
    all I/O devices
    programs (both applications and the OS code)

As a simplification, there are 2 important ways that
most computer systems (architecture's really) use to acheive
access control of resources:
  1.  memory access restriction.
  Each program is allocated a portion of memory.  This portion
  will contain program code and data, and space for whatever
  is needed by the program.

  At EACH memory access, the address is checked (by hardware)
  to see if the address falls within the boundaries set for the
  program.  If the address is OK, the memory access continues.
  If the address is not within the program's allowable memory,
  then the hardware generates an exception (an addressing error

  2. privileged instructions.
  Specific instructions within the instruction set can only be
  executed by the OS code.  To make this work, there must be
  one or more bits in a register somewhere that identify the
  privilege level of the currently running program.  This bit
  is checked each time an instruction is decoded.  Each instruction
  has its own required privilege level.
  If the current privilege level isn't enough to execute a
  decoded instruction, then the hardware must generate an
  exception (trap).


Intel's implementation of this:

  There are 4 levels of privilege
     0  The most privileged, allowed to do everything/anything.
	The OS will be given this level of privilege.
     3  The lowest privilege, restricted.
	Most applications (user programs) will have this level.

  Associated with each program is a descriptor.  In that
  descriptor is the Current Priviledge Level (CPL).

  Associated with each segment of memory is a descriptor.  In that
  descriptor is the Descriptor Priviledge Level (DPL).  The DPL
  is the privilege level needed to access memory within the boundaries
  of the segment.

  Associated with every instruction in the instruction set is
  a required privilege level. (Intel determines this.)
  An example of an instruction that requires privilege level 0
  for execution is the instruction that loads the IDTR.

  At each instruction decoding:
    The CPL is compared with the instruction's required privilege
    level.  If CPL is not privileged enough (when CPL > required
    privilege level), an exception is generated.
  At each memory access:
    The CPL is compared with the DPL.  If CPL is not
    privileged enough (when CPL > DPL), an exception is generated.
    Note that these are memory accesses for EITHER instruction
    fetches OR data.


problem:  Multiple interrupt requests can arrive simultaneously.
	  Which one should get handled first?

general solutions:
     FCFS -- the first one to arrive gets handled first.

         difficulty 1) This might allow a malicious/recalcitrant
         device or program to gain control of the processor.

         difficulty 2) There must be hardware that maintains
         an ordering of pending exceptions.

     prioritize all exceptions -- the one with the highest priority
	 gets handled first.  This is a common method for solving
	 the problem.

	 Priorities for various exceptions are assigned either by
	 the manufacturer, or by a system manager through software.
	 The priorities are normally set when a machine is 
	 booted (the OS is started up).

         difficulty 1) Exceptions with the same priority must
	 still be handled in some order.  Example of same priority
	 exceptions might be all keyboard interrupts.  Consider
	 a machine with many terminals hooked up.

	 The instruction fetch/execute cycle becomes:
	  1.  any interrupts with a higher priority than whatever
	      is currently running pending?
	  2.  fetch
	  3.  PC update
	  4.  decode
	  5.  operands
	  6.  operation
	  7.  result

	     NOTE:  This implies that there is some hardware
	     notion of the priority for whatever is running
	     (user program, keyboard interrupts, clock interrupt, etc.)

Intel's solution:
  Hardware is placed in a chip separate from the processor.
  This separate chip is called the Programmable Interrupt
  Controller (PIC), and it makes the decisions about what interrupts
  are given to the processor, and which come first.  

In general, what should get given the highest priority?
   clock? power failure?  thermal shutdown?  arithmetic overflow?
   keyboard?  I/O device ready?

   priorities are a matter of which is most urgent,
   and therefore cannot wait, and how long it takes
   to process the interrupt.
   -- clock is urgent, and takes little processing,
      maybe only a variable increment.
   -- power failure is very urgent, but takes a lot
      or processing, because the machine will be stopped.
   -- overflow is urgent to the program which caused it,
      because it cannot continue.
   -- keyboard is urgent because we don't want to lose
      a second key press before the first is handled.


Can an exception handler itself be interrupted?
   If the answer is NO, then we have what is called a nonreentrant
   exception handler.
Why would we want to do this?
   There are many details to get right to make this possible.
   The instruction fetch/execute cycle remains the same.  At
   the beginning of EVERY instruction (even those within
   the exception handler), a check is made if there are
   pending interrupts.  

      The instruction fetch/execute cycle must be expanded to

       1. Handle a pending interrupt that is of a higher priority
       than the currently executing code.
       2. instruction fetch
       3. PC update
       4. decode
       5. get operand(s)
       6. operation
       7. store result

   The exception handler must be modified so that it can
   be interrupted.  Its own state must be saved (safely).
   Nothing can interrupt while this state is being saved.

   The Intel implementation of this allocates a bit within the
   EFLAGS register, called the Interrupt Enable Flag (bit #9).
   When this bit is 0, interrupts (maskable ones) are disabled.
   When this bit is 1, interrupts are enabled.
   On the way to executing the code of an exception handler,
   IF is cleared.
   The iret instruction restores interrupts to their enabled

   With the IF bit, we automatically have nonreentrant exception

   To allow reentrant handlers (ones that can be interrupted),
   the exception handler must reenable interrupts.