Review of Interrupts & Exceptions

Review of Interrupts & Exceptions

The use of terminology varies from vendor to vendor. Intel terminology is used here, except as noted.

There are two kinds of special control transfers, implemented by similar mechanisms: Interrupts and Exceptions.

(Motorola calls them externally or internally caused exceptions, respectively.)

What happens when an interrupt/exception occurs?

1. Control is transferred to a handler procedure
   (previously associated with the interrupt/exception)
   This means the value of the IP (a.k.a. PC)x is changed.
2. No state information is lost.
   This means the old value of the IP is saved.
3. Usually, other state information may be change
   (e.g. privilege mode, interrupt masking state, stack pointer)
   The old values must also be saved.

Interrupt Vectors -- Intel 8086 Architecture

• Each interrupt/exception has an 8-bit number
  This is called the VECTOR NUMBER (IRQ number)
  
• Vector number is index into a table of interrupt descriptors

      e.g.  31           16 15             0    (bit addresses)
            ---------------------------------
            |       CS      |      IP       |   (register values)
            ---------------------------------
            |       |       |       |       |   (byte addresses)
               m+3    m+2     m+1      m

• An interrupt descriptor includes the address of a handler procedure (given by the CS and IP values)

Saved State

Stack save area for 8086 (80386 real mode):

-------------------------------------------------
|    FLAGS      |       CS      |      IP       |   (register values)
-------------------------------------------------
|       |       |       |       |       |       |   (byte addresses)
   SP+5    SP+4    SP+3    SP+2    SP+1    SP

Mask

• Some interrupts/exceptions may be masked
• Masked interrupts are held pending
  masked debug traps are discarded.
• Masking is done via bits in the FLAGS register
• Interrupts/traps are masked automatically on transfer to handler, and restored by IRET instruction
• Interrupts/exceptions are prioritized by the CPU

  Intel:

  Debug faults	Highest
  Non-debug faults
  Trap instructions (INT n, INTO)
  Debug traps
  NMI interrupt
  INTR interrupt	Lowest

• Interrupt sources may also be prioritized by interrupt controllers
  (sometimes abbreviated PIC for "Peripheral Interrupt Controller")

Fan-In

Interrupts may come from several sources, which fan in through controllers.

             --------------
   source--->|            |
             | controller |-----|
   source--->|            |     |     INTR    -------
      :      --------------     |-------+---->| CPU |
      :      --------------     |     vector  -------
   source--->| controller |-----|             ^
             --------------                   mask/unmask
                   ^
                   disable/enable

The controller can preserve some info. about source
via the vector value.

Interrupt Handlers

• are procedures invoked by the hardware
• are the basis for hardware-supported concurrent (interleaved) processes
• ordinarily start out with the causing interrupt masked
• must determine the source of the interrupt
• generally does some I/O with controller and the device
• may disable/enable interrupt at the controller level
• must acknowledge the interrupt to the device that caused it
  before it will remove the interrupt signal
  or generate another interrupt

Preventing Interrupts

Can be done at several levels:

• Mask all interrupts (CLI/STI)
• Disable a specific interrupt, at the controller
• Postpone acknowledgment of interrupt
  Danger: interrupt will likely just repeat
  since device will not know it has been handled

See also separate notes on how to mask individual interrupts at the controller level for the I386 architecture in the context of the Linux kernel.