Re: device matching at mainbus

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I'm simply don't undestand the relationship between the IPL, the
> vector and the address of the service routine.

You can find parts of this in the VAX Architecture Reference Manual and
the rest in the documentation for your hardware (or nowhere, if the
available doc for that hardware doesn't mention it).

When a hardware interrupt occurs, the hardware supplies the CPU with a
priority level and vector.  In some cases these are fixed, dedicated to
that particular interrupt source.  (Examples would be the interval
count timer, the one controlled by ICCS and on some hardware ICR and
NICR also, and the console interrupts on hardware that uses IPRs 32-35
for console interaction.)  In other cases one part, the other, or both
may vary depending on the hardware (which bus, which interrupt line,
that sort of thing).

Assuming that the IPL isn't low enough to be masked by the current IPL,
the CPU then takes the interrupt.  This means fetching a value from a
location calcuated from the SCBB (IPR 17) and the vector provided by
the hardware.  The low two bits specify how the interrupt is taken
(NetBSD uses only two values, I think, specifying kernel mode on the
kernel stack and kernel mode on the interrupt stack); the rest
specifies the handler address.  The CPU then stacks a little state (the
PC and PSL as of the interrupt, I think) on the relevant stack and
picks up execution at the handler address.  In NetBSD's case, this
routine will usually stack a bit more stuff and pass control to C code;
as of 5.1, this is in sys/arch/vax/vax/intvec.S.  The same mechanism is
used for CPU-internal faults and traps such as integer divide-by-0 and
reserved opcodes; the difference is that the vectors for hardware
interrupts lie in a different range - again, see intvec.S.

If the CPU's current IPL doesn't permit the interrupt to be taken,
nothing happens until the CPU's IPL is lowered enough to allow it.  If
the interrupt is still being requested then (which may or may not be
the case, depending on the hardware and the circumstances), the
interrupt is taken then.  (To borrow hardware terminology from
elsewhere, this means that at this level interrupts are
level-triggered; if there are interrupt interfaces that are
edge-triggered, something must latch them before the CPU interrupt
machinery sees of them.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B