Weekly Classic Computer Trivia Question (20150112)

[Johnny Billquist]

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
>>>> see
>>>> 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 
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 
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.

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

-- 
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