Transporting an LGP-30
linimon at lonesome.com
Fri Dec 30 01:09:12 CST 2016
On Thu, Dec 29, 2016 at 11:51:27PM -0600, Jon Elson wrote:
> There were instructions that would copy a whole long line of data to
> the short lines so that these could be accessed every 4 word times,
> instead of having to wait a full drum revolution for the next word.
Yeah, I had forgotten about the short lines.
IIRC there are 109 words on a full drum track (I am going to hand-wave
about the metadata on the track because otherwise your brain would
explode.) So 29msec to watch the 109 words go around. Oh, did you
think that instructions only took one word-time to execute? hahahahahah.
So you had to understand the period of time each instruction would run,
before you picked the address of the next instruction. So you optimize
for that for about the first, say, 80 instructions of the code on that track.
Good for you! But now ...
The rest of the instruction slots probably aren't going to be optimal. In
fact, Murphy being who he is, there are almost certainly pessimal.
Now, do it again, _just slightly_ de-optimizing your layout of the first 80
and see if you can cram the rest in without wasting too many drum cycles.
Lather, rinse, repeat.
(as you might imagine, most coding was done in machine language -- the
compilers trying to deal with this was a nightmare. And waaaaaay slow.)
> Programming the G-15 was massively arcane, with all sorts of side effects
> and especially tricks to improve performance, so your program would run
> in a day, instead of a couple WEEKS!!!!
It was worse.
There were occasions where you wished to *pessimize* access.
Again, these are 50-year-old bits in my brain, but it may have had something
to do with waiting for the multiply and divide to finish up. Or perhaps it
was I/O. I was not doing enough heavy programming to encounter that.
After all, it was my first machine.
So easy to learn!
More information about the cctech