Weekly Classic Computer Trivia Question (20150112)
bqt at update.uu.se
Mon Jan 12 12:55:12 CST 2015
On 2015-01-12 19:43, Vincent Slyngstad wrote:
> From: Johnny Billquist: Monday, January 12, 2015 10:21 AM
>> On 2015-01-12 19:17, Johnny Billquist wrote:
>>> On 2015-01-12 18:19, Vincent Slyngstad wrote:
>>>> One answer might be "the skip chain". Since interrupts weren't
>>>> vectored, it was necessary to query each device in priority order to
>>>> if it was currently requesting interrupt service.
>>> Ah. Good point. I forget to include this in the possible interpretations
>>> of interrupt latency.
>> Actually. This needs some correction. The interrupt skip chain itself
>> is not the latency. The skip chain is just some extra time required to
>> actually jump to the correct interrupt handler. The interrupts are
>> (normally) off until the interrupt handler finishes.
> They'd better be off until the last device is in service, or you'll get
> re-entry problems in the interrupt service routine. In practice, I've
> never seen interrupts on during a PDP-8 service routine.
A more correct statement would be that if you enable interrupts in your
interrupt handler you must first save all the context of the current
interrupt, so you can restore it before returning from the current
It's not really that hard. Essentially you must store the contents of
address 0, and probably also make sure you do not get a second interrupt
from the same device, since I doubt you want to write a reentrant
interrupt handler. (But that is normally the case anyway, since most
devices need some kind of operation to enable a new interrupt to be
But if another device generates an interrupt, you'll be fine, unless you
have some other pieces of code both interrupt handlers would share, in
which case there are probably more things to deal with.
(Essentially, unless you take special care, code isn't reentrant on a
PDP8, but I assume you know this. It's just that unless you share code
between interrupt handlers, the only thing needed to be stashed away
before enabling interrupts is the return address.)
>> The skip chain is just a smaller part of that whole thing.
> OK, but it is a significant overhead compared to later (vectored)
> interrupt system designs, and means it takes longer to get to where
> you're going.
True. But the skip chain is still for most cases just a minor part of
the whole execution time of an interrupt handler.
> The un-vectored design also means more problems with re-entry, since all
> the interrupts call the same routine. And the JMS instruction design
> makes it a bear to write re-entrant code on a PDP-8.
Yes. But it don't have anything to do with the vectored or not
interrupts. In fact, there were some devices who generated vectored
interrupts on the PDP-8. The KL8A comes to mind.
It's all about the fact that the return address for interrupts is always
stored in address 0. Makes no difference how you eventually locate the
actual interrupt handler.
> I think it comes back to the "what do we mean by latency" question.
Yeah. That one I'm still not clear on. :-)
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the cctalk