6 ms·

My favorite early airline reservation system (mainly because of the name) is the 1952 “Magnetronic Reservisor”, which was (IIRC, I read a paper about this a few

My favorite early airline reservation system (mainly because of the name) is the 1952 “Magnetronic Reservisor”, which was (IIRC, I read a paper about this a few years ago but can’t seem to find it now) an electromechanical system built around a magnetic drum, but with special-purpose control circuitry rather than a general-purpose computer. Reading about the design made me very grateful that I can just use a SQL database rather than having to design my schema in hardware.

Animats 5y ago
What we call a computer today is a stored program, general purpose, electronic digital computer. This was a known goal before WWII, at least within IBM. But each of those hardware features had to be developed. So, along the way, there were things like this reservation system which checked only some of the boxes on that list. 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-computer.1951.102646303.pdf http://s3data.computerhistory.org/brochures/univac.file-comp...
- YeGoblynQueenne 5y ago
  >> Early electronic memory devices were the Williams tube (too expensive, not big enough), delay lines (too slow), and magnetic drums (too slow). 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
  - Animats 5y ago
    That was Knuth's high school project - an angular-optimizing assembler for the IBM 650, which executed its programs from drum memory. The IBM 650 is notable for being the first time "stored program digital computer" and "affordable" got anywhere near close.
    - monocasa 5y ago
      It's a core part of the classic story of Mel too. https://web.archive.org/web/20170309215507/http://www.pbm.com/~lindahl/mel.html 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.

Animats 5y ago

What we call a computer today is a stored program, general purpose, electronic digital computer. This was a known goal before WWII, at least within IBM. But each of those hardware features had to be developed. So, along the way, there were things like this reservation system which checked only some of the boxes on that list. 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-computer.1951.102646303.pdf http://s3data.computerhistory.org/brochures/univac.file-comp...

YeGoblynQueenne 5y ago
>> Early electronic memory devices were the Williams tube (too expensive, not big enough), delay lines (too slow), and magnetic drums (too slow). 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
- Animats 5y ago
  That was Knuth's high school project - an angular-optimizing assembler for the IBM 650, which executed its programs from drum memory. The IBM 650 is notable for being the first time "stored program digital computer" and "affordable" got anywhere near close.
  - monocasa 5y ago
    It's a core part of the classic story of Mel too. https://web.archive.org/web/20170309215507/http://www.pbm.com/~lindahl/mel.html 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.