https://www.nsa.gov/portals/75/documents/news-features/decla...
https://www.nsa.gov/portals/75/documents/news-features/decla...
http://web.mit.edu/STS.035/www/PDFs/flamm.pdf
I'm off to figure out what instructions were removed from Atlas II when AFSA granted approval for it to be sold commercially. (I feel like I've read about this before and they were to-do with bit population but I can't rightly recall...)
Some good came out of that, but there was a long detour into cryogenic computing. They found a way to make gigahertz components, cryotrons. The trouble was, they couldn't make them small, or cheap, or integrated. So it was a dead end. What's come out of NSA over the years indicates that a full cyrotron computer was never built, but some "analytic tools", probably key-testers of some sort, were made. (The WWII Bombe and Colossus machines were key-testers, like Bitcoin miners, not general purpose computers.)
Drum memory was slow but you could time things so that one instruction finished processing just as the next one reached the head. Can't do that with core :P
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!
That was the heyday of special-purpose systems. Reservisor, Plan 55-A (Western Union's Sendmail made with paper tape and relays), Teleregister (stock market quotations), American Totalizator (racetrack systems), special systems for railroads, mechanically programmable Teletype "stunt boxes", plugboard-wired fire dispatching systems...
IBM had electronic arithmetic in test before WWII. But memory was hard. You needed something to store each bit, and that meant building a huge number of somethings. General purpose stored program computing had to wait until someone developed something cheap enough, large enough, and fast enough to store the program. Early electronic memory devices were the Williams tube (too expensive, not big enough), delay lines (too slow), and magnetic drums (too slow). Magnetic core finally got computing moving, but core was a million dollars a megabyte as late as 1970.
Here's an introduction to the UNIVAC File Computer.[1] The program was on a magnetic drum, so you only got maybe one or two instructions per rev. To speed things up, they had a plugboard, so you could wire up small subroutines to be triggered from a single instruction from the drum. Again, you see the struggle against memory cost and slow memory speed.
UNIVAC later hired Gen. Leslie Groves from the Manhattan Project. He thought big. The result was the UNIVAC 1103, the largest vacuum tube computer ever built as a commercial product. That monster came out in 1953. Stored programs in random access memory at last. The 1103 had everything you needed in a computer except affordability. Williams tube random access memory (1024 words of 36 bits each), large numbers of tape drives, peripherals, etc. They didn't sell many, but the successors (1103A, core memory, 1105, some transistors, 1107, all transistors) became more useful.
So, as I've mentioned before, it's not the lack of a theoretical concept of stored program computing that held back early computing. It was developing something in which to store the program and data.
[1] http://s3data.computerhistory.org/brochures/univac.file-comp...