From: utzoo!watmath!watcgl!dmmartindale
Newsgroups: net.unix-wizards
Title: Re: Zero vector interrupts on a VAX
Article-I.D.: watcgl.344
Posted: Sat Apr 16 23:59:33 1983
Received: Sun Apr 17 10:27:50 1983
References: decvax.460

NPR does indeed have priority over any of the BR's, if they occur at the
same time.  However, the case I was describing was one in which there
was no NPR request at the time the UBA committed itself to issuing
the BG, and once the BG is issued no NPR/NPG cycle can occur until
the BG/SACK/INTR/SSYN interrupt transaction is complete.  The interrupt
controllers detect the case where there is an NPR active at the time
the BG reaches them, which is later than the time the UBA committed
itself to the BG.  The grant-stealing I described is actually documented
as a feature of the M7821 interrupt controller in one of the older
PDP11 Peripherals Handbooks (see page 6-32 of the 1975 edition, for
example) and the newer one-chip interrupt controller seems designed
to do it as well.

>From my reading of the UBA description in the VAX Hardware Handbook
it seems that the BG is not issued until the CPU has entered the
UBA interrupt service routine and has tried to read the BRRVR.
My interpretation of what happens is this:
The UBA has to pass back some data as the result of this read.
If the device asserts INTR and presents a vector, that's what gets
returned.  But if the transaction ends without INTR, the UBA just
passes back zero.  On simpler processors, the arbitrator would know
what priority the processor was operating at directly (rather than
having to request an interrupt from the processor to determine whether
it was accepting interrupts) and could thus issue the BG asynchronously
with processor execution.  Then, if the transaction resulted in INTR,
the processor would take the interrupt, while if the BG simply resulted
in SACK and then nothing because of a stolen grant, the processor would
never need to know about it, and the arbitrator could continue along
its merry way.

	Dave Martindale