12 Jan
2015
12 Jan
'15
8:10 a.m.
This weeks question comes from Warren Stearns. It is a little obscure and
specific to the PDP-8 family of computers.
What is the source of the greatest latency in the interrupt system on a
PDP-8.
I have three answers, two of the answers depends on the options fitted to
an 8.
Why would this have been an important question? Interrupt latency would be
extremely important in the field of data collection which was one of the
principal early uses of these machines. My particular 8 was used for
exactly this purpose in the Summer when it was hauled to a radar site and
collected weather research data for the Institute of Atmospheric Sciences.
I believe it was used for this from 1969 through 1972. I have several
hundred DECTapes with some of this data. The surprising thing is we don't
see any problems reading DECTapes that haven't been out of their box since
the early 70's.
Doug Ingraham
PDP-8 S/N 1175
12 Jan
12 Jan
9:19 a.m.
From: Doug Ingraham: Monday, January 12, 2015 8:10 AM
What is the source of the greatest latency in the
interrupt system on a
PDP-8.
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.
Another might be "disk I/O". Since most operating systems' device
drivers ran with interrupts masked, this meant that when the buffer
filled and had to be written, significant real time (milliseconds to
seconds, depending on the device) could be involved. The alternative
(interrupt driven mass storage) meant replicating significant O/S code,
and meant you had to write your own drivers to change storage devices.
Vince
10:17 a.m.
On 2015-01-12 18:19, Vincent Slyngstad wrote:
From: Doug Ingraham: Monday, January 12, 2015 8:10 AM
Ah. Good point. I forget to include this in the possible interpretations
of interrupt latency.
What is the source of the greatest latency in the
interrupt system on a
PDP-8.
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. Another might be "disk I/O". Since most
operating systems' device
drivers ran with interrupts masked, this meant that when the buffer
filled and had to be written, significant real time (milliseconds to
seconds, depending on the device) could be involved. The alternative
(interrupt driven mass storage) meant replicating significant O/S code,
and meant you had to write your own drivers to change storage devices.
Uh? Disk I/O is normally DMA. It is not performed while you are in the
device driver. The device generates an interrupt when it finishes, at
which point you get back into the device driver. While the transfer is
going on, you have interrupts enabled, and are running out in "user
space" normally.
Interrupt driven mass storage was (and is) pretty uncommon, because it
requires so much CPU. But of course, for those who do, you transfer only
at interrupt time, so you are not bound by the disk speed anyway.
And of course, you also have things like OS/8, which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
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
10:21 a.m.
On 2015-01-12 19:17, Johnny Billquist wrote:
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. The skip chain is
just a smaller part of that whole thing.
And I assumed that the question was about when interrupts were enabled,
which they are not at the point when the skip chain executes.
Consider the skip chain just a part of the interrupt handler. It is no
different from an external point of view.
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
From: Doug Ingraham: Monday, January 12, 2015
8:10 AM
Ah. Good point. I forget to include this in the possible interpretations
of interrupt latency. What is the source of the greatest latency in the
interrupt system on a
PDP-8.
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.
10:43 a.m.
From: Johnny Billquist: Monday, January 12, 2015 10:21 AM
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. 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.
I think it comes back to the "what do we mean by latency"
question.
Vince
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
11:43 a.m.
From: Johnny Billquist: Monday, January 12, 2015 10:55 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
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.)
You've never tried to do it on a PDP-8, I expect. Since there's no stack,
and static storage won't be reentrant, it's a nightmare. At a minimum,
you'd need a routine to emulate "push"/"pop" and "call"
type operations,
and you'll have to remember to have interrupts off when you call them,
unless you want to use MQ to store the return address or something.
(Even then the stack routines will need to disable interrupts while they
do their thing).
Another way to view it is that interrupts effectively introduce a kind
of multi-threading, with the attendant complexity. That's really
incompatible with an "all static storage" machine like the PDP-8,
as everyone's always stomping your variables (even temporaries
and return addresses).
Vince
12:38 p.m.
On 2015-01-12 20:43, Vincent Slyngstad wrote:
From: Johnny Billquist: Monday, January 12, 2015 10:55
AM
Of course I've done it. I suspect there is not much I have not done on a
PDP-8. I've written programs on PDP-8 systems for over 30 years by now...
No, you do not need a push/pop to have interrupts enabled while in an
interrupt handler on a PDP-8. As long as you know the same interrupt
will not trigger, all you need to do is store the return address from 0
somewhere else before ION, and then write it back to 0 after IOFF.
Like I said, with the provisions that you do not reuse the same
functions from different interrupt handlers, and you know that the same
device don't interrupt again.
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.)
You've never tried to do it on a PDP-8, I expect. Since there's no
stack, and static storage won't be reentrant, it's a nightmare. At a
minimum, you'd need a routine to emulate "push"/"pop" and
"call" type
operations, and you'll have to remember to have interrupts off when you
call them, unless you want to use MQ to store the return address or
something. (Even then the stack routines will need to disable interrupts
while they do their thing). Another way to view it is that interrupts effectively
introduce a kind
of multi-threading, with the attendant complexity. That's really
incompatible with an "all static storage" machine like the PDP-8, as
everyone's always stomping your variables (even temporaries
and return addresses).
Yes. And some of the same issues are true no matter what architecture.
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
1:34 p.m.
New subject: Reentrant PDP-8 code (was Re: Weekly Classic Computer Trivia Question (20150112))
From: Johnny Billquist: Monday, January 12, 2015 12:38 PM
Of course I've done it. I suspect there is not
much I have not done on a
PDP-8. I've written programs on PDP-8 systems for over 30 years by now...
No, you do not need a push/pop to have interrupts enabled while in an
interrupt handler on a PDP-8. As long as you know the same interrupt
will not trigger, all you need to do is store the return address from 0
somewhere else before ION, and then write it back to 0 after IOFF.
Well, and the AC and flags and any other context that the ISR needs.
Essentially, a "one deep stack" for the context, which is much easier
to implement.
Like I said, with the provisions that you do not reuse
the same
functions from different interrupt handlers, and you know that the same
device don't interrupt again.
Yep. Generally, you can't share any storage between the various
routines while the interrupts are on, and you have to also prevent
re-entry of the routines you are already in.
Vince
1:38 p.m.
New subject: Reentrant PDP-8 code (was Re: Weekly Classic Computer Trivia Question (20150112))
On 2015-01-12 22:34, Vincent Slyngstad wrote:
Yep.
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
From: Johnny Billquist: Monday, January 12, 2015 12:38
PM
Every interrupt, even if not nested, needs to save the AC, link, and a
bunch of other stuff.
But yes, if you centralize that part, then it also needs to be stashed
away before you allow another interrupt. It's two more words.
Of course I've done it. I suspect there is
not much I have not done on
a PDP-8. I've written programs on PDP-8 systems for over 30 years by
now...
No, you do not need a push/pop to have interrupts enabled while in an
interrupt handler on a PDP-8. As long as you know the same interrupt
will not trigger, all you need to do is store the return address from
0 somewhere else before ION, and then write it back to 0 after IOFF.
Well, and the AC and flags and any other context that the ISR needs.
Essentially, a "one deep stack" for the context, which is much easier
to implement. Like I said,
with the provisions that you do not reuse the same
functions from different interrupt handlers, and you know that the
same device don't interrupt again.
Yep. Generally, you can't share any storage between the various
routines while the interrupts are on, and you have to also prevent
re-entry of the routines you are already in.
10:34 a.m.
From: Johnny Billquist: Monday, January 12, 2015 10:17 AM
Interrupt driven mass storage was (and is) pretty
uncommon, because it
requires so much CPU. But of course, for those who do, you transfer only
at interrupt time, so you are not bound by the disk speed anyway.
For other systems maybe, but for the PDP-8, not so much.
And of course, you also have things like OS/8, which
runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
Exactly :-)
Vince
10:42 a.m.
On 2015-01-12 19:34, Vincent Slyngstad wrote:
But anything running constantly with the interrupts off should not be in
the "competition". As it's hardly called latency when you just ignore
the signal.
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
From: Johnny Billquist: Monday, January 12, 2015 10:17
AM
The one I can recall off my head (unless my brain is fooling me) is the
RX8. And it's definitely true for that one.
If you are thinking of the TD8E then you need to remember that this
controller is not even interrupt driven. It is a purely polled
controller. And that one is truly horrible, and difficult to even use in
an interrupt driven system. It can be sortof made to work with the help
of timers, calculations, and temporarily turning off interrupt when you
want to do the actual transfers, as it cannot tolerate anything else
interrupting the code while a transfer is in progress.
Interrupt driven mass storage was (and is) pretty
uncommon, because it
requires so much CPU. But of course, for those who do, you transfer
only at interrupt time, so you are not bound by the disk speed anyway.
For other systems maybe, but for the PDP-8, not so much. And of course,
you also have things like OS/8, which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
Exactly :-)
10:48 a.m.
From: Johnny Billquist: Monday, January 12, 2015 10:42 AM
But anything running constantly with the interrupts off should not be in
the "competition". As it's hardly called latency when you just ignore
the signal.
What I've seen is systems that collect data with interrupts on, but do
have to turn interrupts off when calling OS/8 services, or OS/8 will crash.
AFAIK, all OS/8 services and drivers require this, even things like the
RK05 driver.
Vince
And of course, you also have things like OS/8, which
runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
Exactly :-)
10:57 a.m.
On 2015-01-12 19:48, Vincent Slyngstad wrote:
From: Johnny Billquist: Monday, January 12, 2015 10:42
AM
But anything running constantly with the interrupts off should not be
in the "competition". As it's hardly called latency when you just
ignore the signal.
What I've seen is systems that collect data with interrupts on, but do
have to turn interrupts off when calling OS/8 services, or OS/8 will crash.
AFAIK, all OS/8 services and drivers require this, even things like the
RK05 driver.
Right. But it's not that things will crash in OS/8, but you will get
interrupts as a result of OS/8 operations, which you most probably do
not want, and might not even know how to deal with. And stealing the
completion of an operation through an interrupt might mean OS/8 never
notice that an operation completes.
So you will get OS/8 hangs, and your interrupt system will get
interrupts you never expected.
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
And of course, you also have things like OS/8, which
runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
Exactly :-) 
6:19 p.m.
At 01:17 PM 1/12/2015, Johnny Billquist wrote:
And of course, you also have things like OS/8, which
runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
The OS/8 FORTRAN runtime (FRTS) runs with interrupts enabled. OS/8 in
general doesn't care if interrupts are on, which is how OS/78 (or was
it OS/278?) symbionts worked. So, you can't blame OS/8 for getting into
the way. There's nothing typically in OS/8 that requires interrupts to
be disabled, but it's true that most of OS/8 doesn't do anything to
handle interrrupts.
Interrupt latency? Either you're looking for the length of the "skip
chain", or interrupt blockers like CIF instructions.
-Rick
6:36 p.m.
On 2015-01-13 03:19, Rick Murphy wrote:
At 01:17 PM 1/12/2015, Johnny Billquist wrote:
Well, not entirely true. Yes, FRTS runs with interrupts enabled. But it
disables them before jumping into OS/8, unless I remember wrong.
It's been a very long time since I mucked around inside FRTS...
But the problem is that if you have interrupt enabled, and OS/8 do some
I/O, you will get the interrupt. Meanwhile the OS/8 device driver is
sitting in a polling loop waiting for the interface to indicate it is
finished. The problem is that whenever it is finished, you get the
interrupt. The only way to dismiss the interrupt is to remove the finish
flag, which means the OS/8 device driver will never see it set. And you
"hang".
The other potential problem being that you might get interrupts from
whatever OS/8 is playing around with. Some of which you might not
actually be prepared to handle. Although this is possibly less of a
point, since there is a risk those devices might generate an interrupt
as soon as you enable interrupts anyway. Depends on the device.
And of course, you also have things like OS/8,
which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
The OS/8 FORTRAN runtime (FRTS) runs with interrupts enabled. OS/8 in
general doesn't care if interrupts are on, which is how OS/78 (or was it
OS/278?) symbionts worked. So, you can't blame OS/8 for getting into the
way. There's nothing typically in OS/8 that requires interrupts to be
disabled, but it's true that most of OS/8 doesn't do anything to handle
interrrupts. Interrupt latency? Either you're looking for the
length of the "skip
chain", or interrupt blockers like CIF instructions.
Continue reading the thread. Seems he's looking for the hardware
response to the raising of the interrupt pin on the CPU, and I assume
under the condition that interrupts are enabled.
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
7:20 p.m.
At 09:36 PM 1/12/2015, Johnny Billquist wrote:
I've read the thread, which is why I brought up the CIF stall, since
nobody else has mentioned it.
Maybe that's not what's being asked here, but if you're asking what can
cause latency with interrupts enabled once a device generates an
interrupt, the fact that CIF instructions delay interrupts until the
next JMP instruction seems to be what's being asked here.
-Rick
On 2015-01-13 03:19, Rick Murphy wrote:
Well, not entirely relevant. You recommended that I 'Read the thread'
but I did. I'm responding to the misinformed statements that OS/8
always runs with interrupts disabled, which is false. FRTS basically
requires that I/O drivers be set up before execution starts, so no OS/8
I/O handlers are called once the runtime gets running (assuming just
FORTRAN source.)
ADVENT does dynamic unit assignment, and wraps OS/8 USR calls to
disable/enable interrupts.
At 01:17 PM 1/12/2015, Johnny Billquist wrote:
Well, not entirely true. Yes, FRTS runs with interrupts enabled. But
it disables them before jumping into OS/8, unless I remember wrong. And of course, you also have things like OS/8,
which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
The OS/8 FORTRAN runtime (FRTS) runs with interrupts enabled. OS/8 in
general doesn't care if interrupts are on, which is how OS/78 (or was it
OS/278?) symbionts worked. So, you can't blame OS/8 for getting into the
way. There's nothing typically in OS/8 that requires interrupts to be
disabled, but it's true that most of OS/8 doesn't do anything to handle
interrrupts. It's been a very long time since I mucked around
inside FRTS...
It's been a few months or so for me :) And yes, OS/8 drivers can be
called with interrupts enabled.
Interrupt
latency? Either you're looking for the length of the "skip
chain", or interrupt blockers like CIF instructions.
Continue reading the thread. Seems he's looking for the hardware
response to the raising of the interrupt pin on the CPU, and I assume
under the condition that interrupts are enabled.
8:09 p.m.
On 2015-01-13 04:20, Rick Murphy wrote:
Some... Try it with the TTY driver if you want some fun. :-)
I've read the thread, which is why I brought up the CIF stall, since
nobody else has mentioned it.
Maybe that's not what's being asked here, but if you're asking what can
cause latency with interrupts enabled once a device generates an
interrupt, the fact that CIF instructions delay interrupts until the
next JMP instruction seems to be what's being asked here.
La la.... Sorry. I got stuck on the skip chain, and didn't properly read
your next idea.
Of course! CIF can block an interrupt indefinitely! Nice one!
I totally forgot that one. That is the best suggestion I've seen so far.
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
At 09:36 PM 1/12/2015, Johnny Billquist wrote:
This becomes nit-picking. But since it can be fun, and maybe someone
else might find it interesting...
You could argue that once a program starts, it has full control of the
machine, and can of course turn on and off interrupts as much as it
wants to, even though it was started from OS/8. Of course OS/8 don't
mind, since OS/8 is not even aware, or active, or involved.
OS/8 only comes into the picture if you actually call OS/8. At which
point the question becomes relevant. Otherwise you could regard OS/8
just as a boot loader.
On 2015-01-13 03:19, Rick Murphy wrote:
Well, not entirely relevant. You recommended that I 'Read the thread'
but I did. I'm responding to the misinformed statements that OS/8 always
runs with interrupts disabled, which is false. FRTS basically requires
that I/O drivers be set up before execution starts, so no OS/8 I/O
handlers are called once the runtime gets running (assuming just FORTRAN
source.) At 01:17 PM 1/12/2015, Johnny Billquist wrote:
Well, not entirely true. Yes, FRTS runs with interrupts enabled. But
it disables them before jumping into OS/8, unless I remember wrong. And of course, you also have things like OS/8,
which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
The OS/8 FORTRAN runtime (FRTS) runs with interrupts enabled. OS/8 in
general doesn't care if interrupts are on, which is how OS/78 (or was it
OS/278?) symbionts worked. So, you can't blame OS/8 for getting into the
way. There's nothing typically in OS/8 that requires interrupts to be
disabled, but it's true that most of OS/8 doesn't do anything to handle
interrrupts. ADVENT does dynamic unit assignment, and wraps OS/8
USR calls to
disable/enable interrupts.
Right. So, one of the situations where OS/8 gets called, and then
interrupts must be off.
It's been
a very long time since I mucked around inside FRTS...
It's been a few months or so for me :) And yes, OS/8 drivers can be
called with interrupts enabled. Interrupt latency? Either you're looking for the
length of the "skip
chain", or interrupt blockers like CIF instructions.
Continue reading the thread. Seems he's looking for the hardware
response to the raising of the interrupt pin on the CPU, and I assume
under the condition that interrupts are enabled.
6:37 p.m.
On 2015-01-13 03:19, Rick Murphy wrote:
At 01:17 PM 1/12/2015, Johnny Billquist wrote:
By the way. Thanks for reminding me about the OS/8 printer background
job. I should go back and recheck how that actually did it, as a simple
interrupt enabled setup will have problems, which I mentioned.
I think it might have been OS/278 only, which also means there might be
slushware required...
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
And of course, you also have things like OS/8,
which runs with
interrupts off at all times, to which the answer to the original
question would be "OS/8". :-)
The OS/8 FORTRAN runtime (FRTS) runs with interrupts enabled. OS/8 in
general doesn't care if interrupts are on, which is how OS/78 (or was it
OS/278?) symbionts worked. So, you can't blame OS/8 for getting into the
way. There's nothing typically in OS/8 that requires interrupts to be
disabled, but it's true that most of OS/8 doesn't do anything to handle
interrrupts.
10:10 a.m.
On 2015-01-12 17:10, Doug Ingraham wrote:
This weeks question comes from Warren Stearns. It is
a little obscure and
specific to the PDP-8 family of computers.
What is the source of the greatest latency in the interrupt system on a
PDP-8.
I have three answers, two of the answers depends on the options fitted to
an 8.
What do you mean by interrupt latency here?
The latency before an interrupt is actually propagated to the CPU? The
latency before the interrupt is reacted upon by the CPU (assuming
interrupt are ON I hope...). The latency internal to a controller before
it even might raise the interrupt request?
Why would this have been an important question?
Interrupt latency would be
extremely important in the field of data collection which was one of the
principal early uses of these machines. My particular 8 was used for
exactly this purpose in the Summer when it was hauled to a radar site and
collected weather research data for the Institute of Atmospheric Sciences.
I believe it was used for this from 1969 through 1972. I have several
hundred DECTapes with some of this data. The surprising thing is we don't
see any problems reading DECTapes that haven't been out of their box since
the early 70's.
Why are you surprised? DECtapes have excellent reliablilty. You can
punch holes in them and they will still work.
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
3:57 p.m.
On Mon, Jan 12, 2015 at 11:10 AM, Johnny Billquist <bqt at update.uu.se> wrote:
What do you mean by interrupt latency here?
The latency before an interrupt is actually propagated to the CPU? The
latency before the interrupt is reacted upon by the CPU (assuming interrupt
are ON I hope...). The latency internal to a controller before it even
might raise the interrupt request?
By latency I mean the time between when the interrupt source signals the
presence of an interrupt and when the JMS Z 0 to field 0 takes place.
Doug
4:20 p.m.
On 2015-01-13 00:57, Doug Ingraham wrote:
On Mon, Jan 12, 2015 at 11:10 AM, Johnny Billquist
<bqt at update.uu.se> wrote:
Ok. Assuming interrupts are on. The longest time would be if we have a
data break going on at the same time, since that is done before the
interrupt signal is sampled. And preferrably an instruction that takes a
long time.
Longest would (I think) be the EAE mode B DIV instruction.
Without the EAE, an indirect memory reference would be the longest
instruction I can think of.
On top of that, you would also have one data break cycle. However, I
wonder if the 3 cycle data break (what was it actually called - my
memory is blank right now) actually do 3 DMAs during one instruction
cycle. But that is possible, which would then definitely add a bunch of
time.
What that adds up to in time depends on the CPU...
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
What do you mean by interrupt latency here?
The latency before an interrupt is actually propagated to the CPU? The
latency before the interrupt is reacted upon by the CPU (assuming interrupt
are ON I hope...). The latency internal to a controller before it even
might raise the interrupt request?
By latency I mean the time between when the interrupt source signals the
presence of an interrupt and when the JMS Z 0 to field 0 takes place.
3582
days inactive
3583
days old
21 comments
4 participants
participants (4)
-
bqt＠update.uu.se -
dpi＠dustyoldcomputers.com -
rick＠rickmurphy.net -
vrs＠msn.com