Early Programming Books

[Paul Koning]

> 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:
>> 
>> 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).

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.

> 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