Blocks for All Occasions

The design of the AGC went through several stages, which for the sake of this discussion we'll call "blocks".  However, the different block designs, while similar in many ways, were quite different in others.  Rather than try to cover all of them on one page, the different blocks are covered in separate pages:

However, this page confines itself just to the Block 3 design.


Introduction

The first thing to understand about the Block III AGC is that there's no such thing.  However, if you have had the patience to read much of what we have to say on this site about the architecture of the Block I AGC (used only in a handful of unmanned missions) and especially the Block II AGC (used in all the manned missions), you will see that certain aspects of the architecture seem to have led to related inefficiencies in the software, and that the system could perhaps have had a more-efficient architecture from the ground up. 

Of course, in blithely stating that, we shouldn't pretend that that fact should have been obvious in advance, nor that there weren't inescapable forces that led to this kind of situation.  For one thing, the "feature creep" (over which the developers had no control) on the original development project, combined with the need to maintain a certain backward compatibility in order to keep from having to rewrite the software over and over again, combined too with the inherent multiplicative complexity in increasing instruction and memory word-lengths at the time, would have forced the team to allow only incremental changes to the architecture.

However, that doesn't stop us from speculating about what a better Block III system might have looked like, if the developers were freed from these kinds of restrictions.  But as it happens, we don't need to speculate about it!  As he explains in a footnote in his book, Left Brains for the Right Stuff, original AGC developer Hugh Blair-Smith put together some notes for a hypothetical Block III AGC architecture that he hoped would have doubled the processing speed, and (to quote his words)

"I did the thinking and writing just a few years ago, but strictly in terms of the mid-\9260s technology we actually used. Probably the greatest risk of non-fidelity is in power consumption, because I take advantage of the Harvard architecture to cycle both fixed and erasable memories simultaneously whenever practical (which is mostly)."

And,

"I plan to publish this fantasy on-line for the amusement of all the people around the world who enjoy building hardware or software replicas of the AGC".

Actually, only the second quote is from the book.  While I don't know that "enjoy" is the word I would necessarily use for this activity, Hugh has in fact sent his notes on the topic to us, and we present them here for your delectation.

Hugh's Dream

I quote:

"What I\92d love is for some too-much-time-on-their-hands people to port, say, Luminary 099 from Block II to Block III and see how much shorter and faster it is!"

A fascinating idea, obviously.  One might wish for not merely a port of one or more of the Block II AGC programs, but perhaps even a Block III assembler and simulator.  If you're such a person, give it some thought.  Perhaps it would be your road to fame!

Hugh's Notes

Hugh's notes comprise two Word documents,

and since they haven't exactly been put into a finalized form, he has also taken the trouble to describe the best way of reading them.  I quote, though a brief summary might be, "Don't start with the testing document":

"... you\92ll probably find the testing document pretty opaque, since it records the output of a simulator that existed only in my headbone. In reading the doc, I would recommend starting with the general discussions at the beginning, then skipping over the NI (Native Interpreter) code examples in the middle initially, and going to the \93regular\94 interpreter code examples toward the end—the idea being to get your head around how Block III performs the same kind of interpreter as Block II does. Then dive bravely into the NI part to see how it interprets the two-word format in RAM of what would otherwise have been one-word native instructions in ROM. If you were a professor, you could assign a hapless grad student to do that! The main reason I spent so much design effort on the NI was to make sure the native design could handle it without too much ugliness, and I did make several enhancements to the native design as a result.

"For relatively short pieces of code, like those in the document, it should be possible to have a fairly satisfactory experience just writing source code and eyeballing it for running time in MCT (as well as for what I might call Nortoning)."



This page is available under the Creative Commons No Rights Reserved License
Last modified by Ronald Burkey on 2017-01-11.

Virtual AGC is hosted by ibiblio.org