20000709 KPH

Here's how I intend to deal with interrupt and exception dispatching.

o  During boot time, trap_init fills the whole SCB with stray handlers.
   Since the CPU might save some longwords of data on the stack after
   an exception, we can't just continue from one of these exceptions
   in the general case.  (However, interrupts from devices that come
   through the second and subsequent pages of the SCB should be 
   continuable.)

   The stray handlers might help out with autoprobing interrupts if we
   decide to implement probe_irq_on() and probe_irq_off().

   Dammit, I hate using the term IRQ when talking about VAXen.  It just
   seems so PC-centric...

o  When an interrupt (or exception) occurs and the CPU dispatches to 
   the handler address in the SCB, the only clue we have as to the 
   interrupt or exception number is the handler address.  There is no
   other way to tell which interrupt happened.

   This implies that every interrupt or exception handler must have a
   unique address.

o  When a driver (or other code) calls request_irq(), we allocate a data
   structure (let's call it irqvector) that contains a struct irqaction 
   and a little bit of in-line code.  This code just pushes PC on the 
   stack and jumps to the generic handler.  (It does this by executing
   a JSB instruction.)

   This generic handler sees a stack that looks like:

      SP: handler_PC (inside the irqvector)
          (maybe) exception info
          saved PC
          saved PSL

   The generic handler builds the required pt_regs struct by duplicating
   the saved PC/PSL and saving all the other registers.  This makes the
   stack look like:

      SP: saved R0
          saved R1
          ...
          saved R11
          saved FP
          saved AP
          saved SP
          saved PC
          saved PSL
          saved R0
          handler PC (inside the irqvector)
          (maybe) exception info
          saved PC
          saved PSL

   (The second saved R0 is because we need a working register in the
   handler code.)

   The generic handler then obtains the handler PC from back up the stack,
   then passes this PC, the addr of the pt_regs and exception info to a 
   dispatcher function.  This function is responsible for calculating the
   start address of the irqvector structure and calling irqaction.handler().

   When control returns to the generic handler, it restores the registers,
   clears the stack down as far as the original saved PC and PSL and does
   an REI.

Anyone playing around with this stuff really needs to read the Interrupts
and Exceptions chapter in the VAX Architecture Reference Manual.