21 Jun
2021
21 Jun
'21
4:56 p.m.
On Jun 21, 2021, at 6:03 PM, Chuck Guzis <cclist at
sydex.com> wrote:
On 6/21/21 1:13 PM, Paul Koning wrote:
That may have been after the time when he did the evaluation (early 1960s). The paper in
in the EWD collection, I don't have the number handy.
The reason Dijkstra maligned the 1620 is not because of its lack of registers but because
of its lack of interrupts and inability to save the full execution state.
Somewhere I've got the Dijkstra paper. The 1710 version of the 1620 did
have interrupts and some later versions even had binary math (options). One of the big issues of the original Model 1(Cadet)
and the Model II
was that there were digits with special properties, such as numeric
blank and record mark that had no instructions to test for their
presence--and any attempt to do math (or comparison) with them would
result in an error stop. Even their definition was a bit fuzzy.
Anything that had the 8 and 4 bits set, but not the 2--84 and 841--was a
numeric blank. Same for record and group marks. Rather than multipunch
record marks on my object decks, I used a period, which read in as 821,
but functioned as a record mark. Basically, you read the special digits
in and kept track of where they were.
Speaking of character I/O, I think he also mentioned as a problem the fact that there was
a paper tape reader, but it could not read arbitrary 8-bit patterns.
You could save enough of the execution state via the
Dump Numeric opcode
to see what was going on, but there was no corresponding Read Numeric
opcode to read to the end of core. That was a fault of the I/O
implementation, not the basic system architecture. But then Dijkstra
should talk--how about the wonderful I/O capabilities of the first
version of Pascal?
Pascal was done by Wirth, not Dijkstra. The issue with 1620 state is that you
couldn't do multiprogramming because you could not context switch threads. The
problem is the subroutine call; BB (subroutine returns) uses an invisible register.
On I/O, it's not all that well known but the I/O system on the Electrologica X8 (which
has a separate I/O coprocessor, vaguely like a CDC 6000 PPU but not user-programmable as
far as I know) uses semaphores to communicate between the two engines. There's a
semaphore that tracks the number of pending requests, and another that tracks completions
and controls interrupt delivery. That is in addition to the widespread use of semaphores
in the THE operating system. It's a very nice structure, and very reliable.
paul