It's worth reading that with the goals in mind. He was doing an RFP for a machine suitable for multiprogramming and for ALGOL, and writing about some of the responses. Clearly someone who would propose an IBM 1620 in response lacks clue. One of his criticisms is that you can't save the state to do context switching (true; consider how subroutine returns are done). The 1620 was very successful in its intended market, but that market wasn't where EWD resided. paul

On 01/14/2017 10:45 AM, Jon Elson wrote: My take on the "Branch Back" instruction was that it was useful for debugging and perhaps lowest-level subroutines. The usual subroutine calls were done with a BTM (branch and transmit immediate) instruction, where the immediate operand was the return address. However, this didn't preclude software implementation of call/return stacks. The big issue was that the programmer had to *know* where code was being executed, as there was no way to for software to read the P-counter. Indeed, most machines of the time (1960) didn't implement a stack and even machines like the CDC 6000 (RJ), the PDP-8 (JMS) and IBM S/360 (BALR) required software implementation for reentrancy. My biggest gripe with the 1620 architecture was that there were special "reserved" values for special characters, but there wasn't always a way to test for them. So, for example, "numeric blank" (coded as 8-4) would raise an error if one tried to perform arithmetic with it, but there was no test for its presence in a memory location. Similarly, one could read values into memory that could not be differentiated from similar values. For example, the record mark 8-2 was treated as such even if it was represented as 8-2-1. Given all of that, the 1620 did perform lots of useful work. Later versions of the machine after the CADET added functionality, but AFAIK, never addressed the problem of the inability to read the P-counter from a program. --Chuck

On 01/14/2017 02:29 PM, Cameron Kaiser wrote: Yes, this fits into the context of the System/360. I can't imagine how much CPU time was wasted when people forgot to save R14 before calling a deeper subroutine, causing an infinite loop. Jon

On 01/15/2017 07:35 AM, Paul Koning wrote: More precisely, as I've noted, the P-counter is a write-only register--there is no way for a program to determine its contents. Why IBM chose never to remedy this situation in later revisions is a mystery. If you wanted interrupts, you ordered the 1710 variant of the 1620; complete with RTC. But the 1710 was used mostly for process control. Akin to the 1130/1800 distinction. I suspect that the 1620 was not alone in this. After all, it's a *decimal* machine, which means that alphamerically, it could represent 100 alphameric characters plus record mark, numeric blank and group mark. That's short of the 128 characters that a 7-level paper tape can represent. Dijkstra's objection to the record mark issue is that I/O on the 1620 is value-delimited--on alphameric output, the delimiting record mark is not punched. However, it's perfectly possible to punch a record mark using a Write Numeric instruction. (I/O on the 1620 could be numeric or alphameric; thus a two-digit value could be punched alphamerically as a single character or numerically as two. Dig around in the list of old decimal machines and I'm sure that this behavior wasn't unique. My own thoughts on the 1620 I/O was that it was unnecessarily complex in the interests of keeping it variable-length. AFAIK, you couldn't read just one column of a card on the 1130--you always got the whole shebang. --Chuck