The IBM 650 is notable for being the first time "stored program digital computer" and "affordable" got anywhere near close.

https://web.archive.org/web/20170309215507/http://www.pbm.co...

> Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GO TO! Put that in Pascal's pipe and smoke it.

> Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it.

> "You never know where it's going to put things", he explained, "so you'd have to use separate constants".

> It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.

> I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.

Funny thing though, about the story. Neither the RPC-4000 [1], nor the LGP-30 [2] had an index resiter and the RPC-4000 didn't have an unconditional jump instruction (since "every single instruction was followed by a GO TO!"). The LGP-30 instruction word had two bits between opcode and operand, but the RPC 4000 had none. So Ed Nather's retelling of the hack wouldn't have been possible exactly as he describes it on either computer.

It turns out that Royal McBee had someone design an emulator for the LGP-30 to run on he RPC 4000, that could have ran Mel Kaye's blackjack program [3]. My guess is that Ed Nather is mixing up the two architectures in his mind because of that. Perhaps he was asked to modify Mel Kaye's program to run on the _emulated_ LGP-30 and the details of the two architectures got fudged in his memory. He's writing the story 23 years later so he's entitled to forget some details, I guess.

_______________________

[1] http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-400...

[2] http://ed-thelen.org/comp-hist/lgp-30-man.html

[3] http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Note...

See the following comment:

My name is James William (Bill) Bryner ... In 1960 I was hired by Royal-McBee to write the assembler for the replacement to the LGP-30, the RPC-4000.

Mel Kaye designed the RPC-4000 assembler. It was titled ROAR (Royal-McBee Optimizing Assembler Routine). Edward W. Dubbs and I programmed that assembler. Following that, I wrote an LGP-30 simulator to run on the RPC-4000. This was meant to allow all programs written for the LGP-30 to be executed on the RPC-4000 without further programming. A drum computer simulating a drum computer is agonizingly slow!