5 ms·

LGP-30 – A Drum Computer of Significance

50 points by masswerk 7y ago

jonjacky 7y ago
This machine made ingenious, economical use of the technology available in the mid 1950s. Only 16 instructions. The ALU used all diode logic. The CPU only used a few tubes for flipflops to store control state. The rotating magnetic drum provided all memory -- including CPU registers. A tiny oscilloscope on the front panel showed register contents as they rolled by the read heads!
- twic 7y ago
  How do you implement a whole ALU in diode logic? All i know about diode logic is what it says on the wikipedia page, but according to that, you can't implement a NOT gate, which i would have thought would make it very hard to implement anything of significance - even a half-adder requires a NOT!
  - masswerk 7y ago
    Allegedly, there were just 15 flip-flops, which are reused a lot…
    - kragen 7y ago
      Probably being bit-serial and storing the CPU registers on the drum helped a lot with this. Have you looked at the magnetostrictive-delay-line calculators from the mid-1960s, which used pulses of torsion in a coil of straight-annealed wire instead of a mechanical drum?
      - masswerk 7y ago
        In fact, I just have "Electronic Computers" by S.H. Hollingdale and G.C. Toothill (Pelican / Penguin Books, 1965) besides me. While meant to be popular or introductory to the EE side of computing, this is a wonderful book full of such things! Highly recommended and cheap to pick up on various market places!
        kragen 7y ago
        Thank you for the recommendation! It doesn't seem to be on Libgen or in the Archive's texts collection, and I doubt that I can find a paper copy here in Argentina. Maybe you could scan and upload it; it is presumably in the public domain if it was originally published in the US, since the authors probably did not bother to renew the copyright.
        masswerk 7y ago
        I picked mine up at abebooks.co.uk – it seems to have been quite popular in the UK at the time. Regarding copyright: It was published in the UK. So for the moment EU copyright regulations, 70 years from the death of the author (I guess).
    - masswerk 7y ago
      Here's I found a source for this: Stanley P. Frankel on the design of MINAC and the LGP-30 in IRE Transactions on Electronic Computers. (15 flip-flops, presenting both normal and inverted output to a logical network made of resistors and crystal diodes, providing basic monotonic Boolean functions like And, Or, and Xor.) Stanley P. Frankel, “The Logical Design of a Simple General Purpose Computer” in: IRE Transactions on Electronic Computers, March 1957, pp. 5 [1] [1] https://www.masswerk.at/nowgobang/misc/MINAC-IRE-March-1957.pdf https://www.masswerk.at/nowgobang/misc/MINAC-IRE-March-1957....
      - masswerk 7y ago
        Here's a photo (by Cory Heisterkamp) showing the logic networks from the Ed Thelen's website [1]: http://ed-thelen.org/comp-hist/images/Heistercamp-lgp.jpg http://ed-thelen.org/comp-hist/images/Heistercamp-lgp.jpg (The cards with the rest of the logic are behind and below the main network plane. Mind that this a Control Data model, so it's 1965 or later.) [1] http://ed-thelen.org/comp-hist/lgp-30.html http://ed-thelen.org/comp-hist/lgp-30.html
      - kragen 7y ago
        This is awesome! Thank you! This should make the Boolean equations in the manual quite a bit easier to decipher. XOR isn't monotonic — you can't make X ⊕ Y with diode logic given just X and Y, the way you can make X ∧ Y and X ∨ Y. However, you can make it given X, Y, X̄, and Ȳ. I'm not sure if you can make it with X, Y, and just one of X̄ or Ȳ.
        masswerk 7y ago
        Regarding XOR: This is sloppy quoting of Frankel, who writes about the monotonic functions "And and (nonexclusive) Or" – so, yes, inclusive Or only. However, as described, both the normal and the inverted (negated) outputs of the flip-flops ("toggles") are fed into the network, so there's X and Y and negated X and negated Y available.
        kragen 7y ago
  - kragen 7y ago
    At the RTL or Moore-machine level, a computer consists of some register state (the flip-flops) which changes, at each clock transition, to a deterministic function of its previous state and its input lines at the time. So you need a way to compute the new state as some arbitrary Boolean function of the previous state. The flip-flops each have a Q output and an inverted Q̄ output, which comes for free due to the symmetric construction of the flip-flop from a pair of vacuum tubes and other components. You can form any arbitrary Boolean function of the flip-flop state from a sum of products of the Q and Q̄ variables; it's a simple matter of applying De Morgan's theorem and distributivity. (Or, for that matter, you can use a product of sums by doing it in negative logic.) The flip-flops can supply not just all the memory but also all the inversion, signal level restoration, glitch elimination, and amplification, none of which can be done with diode logic. So, indeed, diode combinational logic is not capable of computing arbitrary Boolean functions of its input lines. But it is indeed capable of computing arbitrary Boolean functions of the flip-flops' state. And that is all that is needed. The LGP-30 manual gives a complete description of how the computation works at the Boolean equation level, a description which I have not yet managed to grok. If you're interested in this kind of thing, you might be interested in notes/non-inverting-logic.html in Dercuano: http://canonical.org/~kragen/dercuano-20190711.tar.gz http://canonical.org/~kragen/dercuano-20190711.tar.gz. (Like most things in Dercuano, it's unfinished.)
deleted 7y ago
[deleted]
progre 7y ago
From the company in "The story of Mel" http://www.catb.org/~esr/jargon/html/story-of-mel.html http://www.catb.org/~esr/jargon/html/story-of-mel.html
- mrob 7y ago
  Or without the irritating formating: http://www.pbm.com/~lindahl/mel.html http://www.pbm.com/~lindahl/mel.html
- YeGoblynQueenne 7y ago
  Mel Kaye's hack was actually performed on an RPC-4000, so the story goes. When I was doing my CS degree and had plenty of time in my hands for that sort of thing, I had a look at the manuals for the two systems and tried to follow Ed Nather's story. It looks like Ed Nather misremembered the story (in his defense it had been several decades since he'd seen it) because the whole hack rested on the machine having an index register bit "between the address and the operation code in the instruction word", but the RPC-4000 had the index register bit ("index tag") at the end of the instruction word [1] and nothing between the current instruction and operand address, which is, I think, the natural reading of "operation code" and "address" respectively. There's also nothing between the operand address and the next instruction address. The RPC-4000 word looks like this: [COMMAND][OPERAND ADDRESS][NEXT ADDRESS][X] |0 4||5 11|12 17||18 24|25 30||31| | | TRACK | SECTOR TRACK|SECTOR What Nather remembers could be an overflow of the NEXT ADDRES field, through the index tag, and into the COMMAND field. It depends on whether the RPC-4000 handled overflows by wrapping or saturation (I can't find that in the manual). On the other hand, Nather's account states that the hack changed an instruction to a jump instruction- and the RPC-4000 does not have a jump instruction, because it doesn't need it: like Nather's story says, every instruction has its own GOTO- in the NEXT ADDRESS field. Here's some alternative ways the hack could have played out, from what I can tell: 1. The hack used the "Branch control" facility. The RPC-4000 had another facility, the "Branch control", an internal flip-flop with only one bit that was turned on when an arithmetic overflow was detected. Kaye could have used this instead of the index tag and Nather may have misremembered it as being the index tag. 2. The hack was actually done on the LGP-30 The hack might also have been possible to pull off on the LGP-30, that had two bits between the opcode and the operand address [2] and an uncontrolled jump instruction ("Unconditional transfer" in the manual). Kaye could have kept those two bits set and caused an overflow, as told in the story. 3. The hack was done on an RPC-4000 emulating an LGP-30. Royal McBee had an emulator written for the RPC-4000, specifically to be able to run LGP-30 programs on the new machine [3]: 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! I bet, the blackjack program that brought everyone to the Royal McBee booth would have been top of the line of the programs to be run on the RPC-4000. Perhaps, then, Nather was working on Mel Kaye's "port" of the original blackjack program, not on the RPC-4000 but on the LGP-30 emulator running on the RPC-4000. Judging from the descriptions of Mel Kaye's programs in Ed Nather's account, just having an emulator for the architecure would not necessarily mean that Kaye's programs would run without any changes on the RPC-4000. I have no clear idea how any of the above could have worked. Just guessing. _____________ [1] http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-4000_Programming_Manual.pdf http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-400... [2] Here's an example from the LGP-30 manual, as in the article: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 (-------) (----------)(------------) order bits track bits sector bits = bring = 20 = 00 ( address = 2000 ) [3] http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Notes http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Note...
kragen 7y ago
It's wonderful to see this investigation being done on such an important early computer; I've attempted to make my way through the logical equations in the carefully preserved manuals, but so far have not finished the job. The LGP-30 appears to be substantially simpler than later minicomputers, even the PDP-8, and I've long wanted to understand how it could work at all. This article should help me quite a bit. Thank you, Norbert! You are a true hero.
- masswerk 7y ago
  You are welcome! :-) Regarding the PDP-8, have a look into "Computer Engineering" by Gordon Bell, Craig Mudge and John McNamara; DEC, 1978. (Quite common to find at a reasonable price, there are even some PDFs circulating, which may be found by your search engine of choice.) Edit: Maybe also of interest, "Computer Structures: Reading and Examples" by Gordon Bell and Allen Newell (McGraw-Hill, Inc., 1971). For availability, see above.
- abraae 7y ago
  It's also interesting to me that these sorts of posts have so much, and so better presented information than was available back in the day to those who had to maintain these machines. For example I found this fascinating animation by kens more useful in understanding how the hydraulically powered 1403 printer worked than any training at the time http://righto.com/ibm1401/printchain.html http://righto.com/ibm1401/printchain.html.
  - masswerk 7y ago
    This animation is great and really informative! Loosely related: https://www.masswerk.at/misc/card-punch-typography/ https://www.masswerk.at/misc/card-punch-typography/ :-)
  - masswerk 7y ago
    One thing I was wondering, but is probably a bit too ephemeral to find out more about in primary sources: I have always been amused by the "DEC Chair", which came with all bigger PDPs. Some of the Royal McBee materials suggest (loosely so) that the LGP-30 came with its own chair as well and that this may have been a broader habit in the first few decades of computing, when computers were still voluminous and expensive. (However, I don't think that IBM did ever ship a chair with their equipment. But this is just a personal impression.) – Are there any personal memories?
radford-neal 7y ago
Ah, the LGP-30! I've actually programmed one, back around 1980 or so, at the University of Calgary. Some friends and I got a collection of computers to play a musical piece. The LGP-30's role was to do the percussion. It was a bit of a challenge to get it to output the rhythm (pounding on the flexowriter) at speed, but we eventually figured out how to get the program to go fast enough for this. Of course, we probably didn't know all the good tricks...
- mkesper 7y ago
  So it could be used as kind of drum computer in nowadays use of the term, too?
drfuchs 7y ago
Learned LGP-30 assembly language for my high-school's programming class back in 1973, but we didn't actually have one, or even access to one. The teacher had learned on a (real) LGP-30, and thought that we students ought to learn how CPUs really worked before graduating to a higher-level language (NEAT/3 for the NCR Century 100 that the school district did have). So, homeworks were handed in on paper, and the instructor would run them in his head. One aspect of programming the LGP-30 is that, by convention, to call function FOO, the caller would store the return address at $FOO and then jump to $FOO+1, where the actual code for FOO started. Then, to return, FOO would do jump to the address in $FOO. So, no recursion was possible by default. (There was a single instruction that did "Store the already-incremented PC at a given location, and jump to just after that location", so it was all very efficient.)
- masswerk 7y ago
  This is really interesting, because this is how later machines did it (at least with sum call instructions). I was actually surprised that the Programming Manual suggested to insert the address directly at the final jump to return. (Regarding recursion, you could emulate a stack by storing the top of stack in a particular address by convention, say 0000, and fix up the 'r' command on the fly to insert PC+2 at this location. Then, every subroutine would look up 0000 for the top of stack and fix up its final jump to return. However, this would seriously mess up the accumulator and you had to store any return values in another conventional address, etc...)
  - drfuchs 7y ago
    Hmmm; you’re closer to correct than I. Actual details are covered in http://ed-thelen.org/comp-hist/lgp-30-man.html#R3.16 http://ed-thelen.org/comp-hist/lgp-30-man.html#R3.16 where it explains that the “R” instruction would store away the address part of what was typically an unconditional branch. So, it was only by convention that this would be kept at $FOO, and that FOO would return by branching to $FOO. A super-smart compiler (they existed) would know the address of the last instruction of each routine, and be able to R into that location directly before calling (actually, just jumping) to $FOO. One other cute thing was that all memory was on a spinning drum, and you could really speed up your program’s execution by placing variables at addresses that were just about to be under the read head when the current operation was being performed. Otherwise, everything had to wait for up to a whole drum rotation. Kind of the original “pipeline stall”.
jonjacky 7y ago
In addition to influencing Lorenz and Licklider, the LGP-30 was also the machine first used by Kemeny and Kurtz at Dartmouth. Their experience with its interactive programming and their discovery that undergraduates could be enthusiastic and effective programmers inspired them to get a bigger/better computer and create BASIC.

50 points by masswerk 7y ago

This machine made ingenious, economical use of the technology available in the mid 1950s. Only 16 instructions. The ALU used all diode logic. The CPU only used a few tubes for flipflops to store control state. The rotating magnetic drum provided all memory -- including CPU registers. A tiny oscilloscope on the front panel showed register contents as they rolled by the read heads!

twic 7y ago
How do you implement a whole ALU in diode logic? All i know about diode logic is what it says on the wikipedia page, but according to that, you can't implement a NOT gate, which i would have thought would make it very hard to implement anything of significance - even a half-adder requires a NOT!
- masswerk 7y ago
  Allegedly, there were just 15 flip-flops, which are reused a lot…
  - kragen 7y ago
    Probably being bit-serial and storing the CPU registers on the drum helped a lot with this. Have you looked at the magnetostrictive-delay-line calculators from the mid-1960s, which used pulses of torsion in a coil of straight-annealed wire instead of a mechanical drum?
    - masswerk 7y ago
      In fact, I just have "Electronic Computers" by S.H. Hollingdale and G.C. Toothill (Pelican / Penguin Books, 1965) besides me. While meant to be popular or introductory to the EE side of computing, this is a wonderful book full of such things! Highly recommended and cheap to pick up on various market places!
      - kragen 7y ago
        Thank you for the recommendation! It doesn't seem to be on Libgen or in the Archive's texts collection, and I doubt that I can find a paper copy here in Argentina. Maybe you could scan and upload it; it is presumably in the public domain if it was originally published in the US, since the authors probably did not bother to renew the copyright.
        masswerk 7y ago
        I picked mine up at abebooks.co.uk – it seems to have been quite popular in the UK at the time. Regarding copyright: It was published in the UK. So for the moment EU copyright regulations, 70 years from the death of the author (I guess).
  - masswerk 7y ago
    Here's I found a source for this: Stanley P. Frankel on the design of MINAC and the LGP-30 in IRE Transactions on Electronic Computers. (15 flip-flops, presenting both normal and inverted output to a logical network made of resistors and crystal diodes, providing basic monotonic Boolean functions like And, Or, and Xor.) Stanley P. Frankel, “The Logical Design of a Simple General Purpose Computer” in: IRE Transactions on Electronic Computers, March 1957, pp. 5 [1] [1] https://www.masswerk.at/nowgobang/misc/MINAC-IRE-March-1957.pdf https://www.masswerk.at/nowgobang/misc/MINAC-IRE-March-1957....
    - masswerk 7y ago
      Here's a photo (by Cory Heisterkamp) showing the logic networks from the Ed Thelen's website [1]: http://ed-thelen.org/comp-hist/images/Heistercamp-lgp.jpg http://ed-thelen.org/comp-hist/images/Heistercamp-lgp.jpg (The cards with the rest of the logic are behind and below the main network plane. Mind that this a Control Data model, so it's 1965 or later.) [1] http://ed-thelen.org/comp-hist/lgp-30.html http://ed-thelen.org/comp-hist/lgp-30.html
    - kragen 7y ago
      This is awesome! Thank you! This should make the Boolean equations in the manual quite a bit easier to decipher. XOR isn't monotonic — you can't make X ⊕ Y with diode logic given just X and Y, the way you can make X ∧ Y and X ∨ Y. However, you can make it given X, Y, X̄, and Ȳ. I'm not sure if you can make it with X, Y, and just one of X̄ or Ȳ.
      - masswerk 7y ago
        Regarding XOR: This is sloppy quoting of Frankel, who writes about the monotonic functions "And and (nonexclusive) Or" – so, yes, inclusive Or only. However, as described, both the normal and the inverted (negated) outputs of the flip-flops ("toggles") are fed into the network, so there's X and Y and negated X and negated Y available.
        kragen 7y ago
- kragen 7y ago
  At the RTL or Moore-machine level, a computer consists of some register state (the flip-flops) which changes, at each clock transition, to a deterministic function of its previous state and its input lines at the time. So you need a way to compute the new state as some arbitrary Boolean function of the previous state. The flip-flops each have a Q output and an inverted Q̄ output, which comes for free due to the symmetric construction of the flip-flop from a pair of vacuum tubes and other components. You can form any arbitrary Boolean function of the flip-flop state from a sum of products of the Q and Q̄ variables; it's a simple matter of applying De Morgan's theorem and distributivity. (Or, for that matter, you can use a product of sums by doing it in negative logic.) The flip-flops can supply not just all the memory but also all the inversion, signal level restoration, glitch elimination, and amplification, none of which can be done with diode logic. So, indeed, diode combinational logic is not capable of computing arbitrary Boolean functions of its input lines. But it is indeed capable of computing arbitrary Boolean functions of the flip-flops' state. And that is all that is needed. The LGP-30 manual gives a complete description of how the computation works at the Boolean equation level, a description which I have not yet managed to grok. If you're interested in this kind of thing, you might be interested in notes/non-inverting-logic.html in Dercuano: http://canonical.org/~kragen/dercuano-20190711.tar.gz http://canonical.org/~kragen/dercuano-20190711.tar.gz. (Like most things in Dercuano, it's unfinished.)

deleted 7y ago

[deleted]

progre 7y ago

From the company in "The story of Mel" http://www.catb.org/~esr/jargon/html/story-of-mel.html http://www.catb.org/~esr/jargon/html/story-of-mel.html

mrob 7y ago
Or without the irritating formating: http://www.pbm.com/~lindahl/mel.html http://www.pbm.com/~lindahl/mel.html
YeGoblynQueenne 7y ago
Mel Kaye's hack was actually performed on an RPC-4000, so the story goes. When I was doing my CS degree and had plenty of time in my hands for that sort of thing, I had a look at the manuals for the two systems and tried to follow Ed Nather's story. It looks like Ed Nather misremembered the story (in his defense it had been several decades since he'd seen it) because the whole hack rested on the machine having an index register bit "between the address and the operation code in the instruction word", but the RPC-4000 had the index register bit ("index tag") at the end of the instruction word [1] and nothing between the current instruction and operand address, which is, I think, the natural reading of "operation code" and "address" respectively. There's also nothing between the operand address and the next instruction address. The RPC-4000 word looks like this: [COMMAND][OPERAND ADDRESS][NEXT ADDRESS][X] |0 4||5 11|12 17||18 24|25 30||31| | | TRACK | SECTOR TRACK|SECTOR What Nather remembers could be an overflow of the NEXT ADDRES field, through the index tag, and into the COMMAND field. It depends on whether the RPC-4000 handled overflows by wrapping or saturation (I can't find that in the manual). On the other hand, Nather's account states that the hack changed an instruction to a jump instruction- and the RPC-4000 does not have a jump instruction, because it doesn't need it: like Nather's story says, every instruction has its own GOTO- in the NEXT ADDRESS field. Here's some alternative ways the hack could have played out, from what I can tell: 1. The hack used the "Branch control" facility. The RPC-4000 had another facility, the "Branch control", an internal flip-flop with only one bit that was turned on when an arithmetic overflow was detected. Kaye could have used this instead of the index tag and Nather may have misremembered it as being the index tag. 2. The hack was actually done on the LGP-30 The hack might also have been possible to pull off on the LGP-30, that had two bits between the opcode and the operand address [2] and an uncontrolled jump instruction ("Unconditional transfer" in the manual). Kaye could have kept those two bits set and caused an overflow, as told in the story. 3. The hack was done on an RPC-4000 emulating an LGP-30. Royal McBee had an emulator written for the RPC-4000, specifically to be able to run LGP-30 programs on the new machine [3]: 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! I bet, the blackjack program that brought everyone to the Royal McBee booth would have been top of the line of the programs to be run on the RPC-4000. Perhaps, then, Nather was working on Mel Kaye's "port" of the original blackjack program, not on the RPC-4000 but on the LGP-30 emulator running on the RPC-4000. Judging from the descriptions of Mel Kaye's programs in Ed Nather's account, just having an emulator for the architecure would not necessarily mean that Kaye's programs would run without any changes on the RPC-4000. I have no clear idea how any of the above could have worked. Just guessing. _____________ [1] http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-4000_Programming_Manual.pdf http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-400... [2] Here's an example from the LGP-30 manual, as in the article: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 (-------) (----------)(------------) order bits track bits sector bits = bring = 20 = 00 ( address = 2000 ) [3] http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Notes http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Note...

kragen 7y ago

It's wonderful to see this investigation being done on such an important early computer; I've attempted to make my way through the logical equations in the carefully preserved manuals, but so far have not finished the job. The LGP-30 appears to be substantially simpler than later minicomputers, even the PDP-8, and I've long wanted to understand how it could work at all. This article should help me quite a bit. Thank you, Norbert! You are a true hero.

masswerk 7y ago
You are welcome! :-) Regarding the PDP-8, have a look into "Computer Engineering" by Gordon Bell, Craig Mudge and John McNamara; DEC, 1978. (Quite common to find at a reasonable price, there are even some PDFs circulating, which may be found by your search engine of choice.) Edit: Maybe also of interest, "Computer Structures: Reading and Examples" by Gordon Bell and Allen Newell (McGraw-Hill, Inc., 1971). For availability, see above.
abraae 7y ago
It's also interesting to me that these sorts of posts have so much, and so better presented information than was available back in the day to those who had to maintain these machines. For example I found this fascinating animation by kens more useful in understanding how the hydraulically powered 1403 printer worked than any training at the time http://righto.com/ibm1401/printchain.html http://righto.com/ibm1401/printchain.html.
- masswerk 7y ago
  This animation is great and really informative! Loosely related: https://www.masswerk.at/misc/card-punch-typography/ https://www.masswerk.at/misc/card-punch-typography/ :-)
- masswerk 7y ago
  One thing I was wondering, but is probably a bit too ephemeral to find out more about in primary sources: I have always been amused by the "DEC Chair", which came with all bigger PDPs. Some of the Royal McBee materials suggest (loosely so) that the LGP-30 came with its own chair as well and that this may have been a broader habit in the first few decades of computing, when computers were still voluminous and expensive. (However, I don't think that IBM did ever ship a chair with their equipment. But this is just a personal impression.) – Are there any personal memories?

radford-neal 7y ago

Ah, the LGP-30! I've actually programmed one, back around 1980 or so, at the University of Calgary. Some friends and I got a collection of computers to play a musical piece. The LGP-30's role was to do the percussion. It was a bit of a challenge to get it to output the rhythm (pounding on the flexowriter) at speed, but we eventually figured out how to get the program to go fast enough for this. Of course, we probably didn't know all the good tricks...

mkesper 7y ago
So it could be used as kind of drum computer in nowadays use of the term, too?

drfuchs 7y ago

Learned LGP-30 assembly language for my high-school's programming class back in 1973, but we didn't actually have one, or even access to one. The teacher had learned on a (real) LGP-30, and thought that we students ought to learn how CPUs really worked before graduating to a higher-level language (NEAT/3 for the NCR Century 100 that the school district did have). So, homeworks were handed in on paper, and the instructor would run them in his head. One aspect of programming the LGP-30 is that, by convention, to call function FOO, the caller would store the return address at $FOO and then jump to $FOO+1, where the actual code for FOO started. Then, to return, FOO would do jump to the address in $FOO. So, no recursion was possible by default. (There was a single instruction that did "Store the already-incremented PC at a given location, and jump to just after that location", so it was all very efficient.)

masswerk 7y ago
This is really interesting, because this is how later machines did it (at least with sum call instructions). I was actually surprised that the Programming Manual suggested to insert the address directly at the final jump to return. (Regarding recursion, you could emulate a stack by storing the top of stack in a particular address by convention, say 0000, and fix up the 'r' command on the fly to insert PC+2 at this location. Then, every subroutine would look up 0000 for the top of stack and fix up its final jump to return. However, this would seriously mess up the accumulator and you had to store any return values in another conventional address, etc...)
- drfuchs 7y ago
  Hmmm; you’re closer to correct than I. Actual details are covered in http://ed-thelen.org/comp-hist/lgp-30-man.html#R3.16 http://ed-thelen.org/comp-hist/lgp-30-man.html#R3.16 where it explains that the “R” instruction would store away the address part of what was typically an unconditional branch. So, it was only by convention that this would be kept at $FOO, and that FOO would return by branching to $FOO. A super-smart compiler (they existed) would know the address of the last instruction of each routine, and be able to R into that location directly before calling (actually, just jumping) to $FOO. One other cute thing was that all memory was on a spinning drum, and you could really speed up your program’s execution by placing variables at addresses that were just about to be under the read head when the current operation was being performed. Otherwise, everything had to wait for up to a whole drum rotation. Kind of the original “pipeline stall”.

jonjacky 7y ago

In addition to influencing Lorenz and Licklider, the LGP-30 was also the machine first used by Kemeny and Kurtz at Dartmouth. Their experience with its interactive programming and their discovery that undergraduates could be enthusiastic and effective programmers inspired them to get a bigger/better computer and create BASIC.