Path: isy!liuida!sunic!mcsun!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!jn11+ From: jn11+@andrew.cmu.edu (Joseph M. Newcomer) Newsgroups: alt.folklore.computers Subject: more frozen designs Message-ID: Date: 19 Apr 91 00:05:10 GMT Organization: Carnegie Mellon, Pittsburgh, PA Lines: 60 This is the story as I remember it. I think Jim Tomayko reads this newsgroup and he is certainly more knowledgeable than I (NASA computer history is one of his specialties). So I hope he will correct any errors in this story... When I took the architecture course at CMU we studied any number of machines. One was, as I remember, the Apollo Guidance Computer. The history of the space program is fascinating. In terms of logistics, many simultaneous research-level projects were attempting to solve problems and produce working solutions in time to launch a man-rated vehicle. One project was the guidance computer. The problem domain was examined, and a machine capable of handling this was specified. It had some prime-number bits of words (DoD embedded machines tended to word lengths like 19 bits and 29 bits because the cost of core or other memory was many dollars per bit, and for DoD ratings these prices were multiplied). So the minimum memory configuration capable of doing the job was specified. The machine had, as I recall, 8 opcodes. As is typical of these projects, the processor was bid to one firm, the software to another, and the memory to a third. The memory was tricky; it was mostly ROM (a technology that was unbelievably Rube Goldberg, e.g., plated wire ROM, braided core ROM, transformer ROM, and other even more bizarre technologies. I belive the AGC used braided ROM with multiholed cores), some RAM, and had a very distinct power budget, size budget, and weight budget. Like, I mean, these guys worried about *grams* on a multiton vehicle...because if they didn't, it wouldn't lift off. So everything is progressing, except that they can't fit the program into the nK bytes available. "If we only had some more opcodes we could eliminate some of these tedious computations and use a single instruction" said the software types. "Fine, we'll redefine the processor" said the processor types. "We can't give you any more bits" said the memory types. The problem was that the memory just barely had a possibility of being buildable as specified; if they had to add one more bit per word and the associated circuitry (can you say "SSI"?) they couldn't fit it in the package, it would take more power than was specified, and it would be heavier. But if they couldn't get more powerful instructions, they would need more words of memory; if they couldn't even get an extra *bit* they certainly couldn't get another 8K-or-whatever *words*. The solution was both clever and bletcherous. The overflow bit became part of the opcode. To get the extra opcodes, the program would add-to-memory an accumulator value that would cause an overflow when added to the instruction that was in memory. Since the instructions were in ROM they didn't get modified, but the added bit of the overflow gave 8 more opcodes. I only presume that these opcodes were powerful enough that the extra instructions required to generate them cost less than the instructions they replaced. I have long since lost the article reprint we used. Dave Parnas, who taught the course, had a great time with this particular machine... All I know is: Mel would have *loved* it! joe