30 Oct
2019
30 Oct
'19
2:35 p.m.
On Wed, Oct 30, 2019 at 2:17 PM Tapley, Mark B. via cctalk <
cctalk at classiccmp.org> wrote:
All,
my daughter is well aware of my affinity for old computers and software,
and, as usual, she pointed out that there?s an XKCD for that:
https://xkcd.com/2221/
I found this remarkably accurate.
For the dps8 emulator, I wrote (for expediency) the I/O code to complete
immediately. When the CPU executes an I/O instruction, the I/O is completed
and the interrupt posted before the next instruction is executed. As the
emulator was (at that point) single threaded, there was no performance
reason to do otherwise, and delaying interrupt delivery was additional code
that I didn't want to write and debug. The consensus in the Multics
community was that this was *probably* OK; the interrupt structure was
robust and the interrupt handling code well written, and should be able to
cope. But everytime a runtime failure occured, the question popped up: is
zero-latency I/O the issue? I ended up adding code to delay interrupt
delivery as a run-time configuration option so that that possibility could
be checked.
The XKCD is dead on for me. I have had that conversation.
-- Charles