12 Jan
2015
12 Jan
'15
10:55 a.m.
On 2015-01-12 19:43, Vincent Slyngstad wrote:
True. But the skip chain is still for most cases just a minor part of
the whole execution time of an interrupt handler.
From: Johnny Billquist: Monday, January 12, 2015 10:21
AM
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
interrupt.
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
On 2015-01-12 19:17, Johnny Billquist wrote:
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. On 2015-01-12 18:19, Vincent Slyngstad wrote:
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. One answer might be "the skip chain".
Since interrupts weren't
vectored, it was necessary to query each device in priority order to
see
if it was currently requesting interrupt service.
Ah. Good point. I forget to include this in the possible interpretations
of interrupt latency. 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
generated.)
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. 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
--
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