Following my recent blog on Banana Registers, I've been recollecting and reflecting on designs that didn't perform their function in life in quite the way I had anticipated.
In turn, this led me to recall a story one of my design engineer friends once related to me about a goof made in the design of a mainframe computer with which he had been associated (the computer, not the goof).
In order to fully appreciate the magnitude of this design blunder, let's first remind ourselves how things used to be in the not-so-distant past. (See also my recent column, A 1960 Incarnation of Google.) If you worked for a very large company circa the 1960s and 1970s, the chances are that the company would own -- or have access to -- a humongous mainframe computer.
An example of a humongous mainframe computer.
In those days of yore, users didn't have access to their own personal computers or workstations -- instead, they worked on "dumb terminals" that were connected to the mainframe. The idea was that it was inefficient to have only a single user working on the computer, which would spend a disproportionate amount of time waiting for the user to press the next key on the keyboard. The solution was to have tens or hundreds of users time-sharing the computer's resources; that is, the computer would spend small slices of time dealing with each user in turn. To each user, it appeared as though he or she had full access to the machine.
Users working on time-sharing "dumb" terminals.
OK, now consider a program statement like "a = b + 2," where "a" and "b" are variables in some high-level programming language. If this statement were converted into machine code that was stored in the computer's memory, it would typically look something like the following (note that I'm visualizing this example in terms of a simple microprocessor with an 8-bit data bus and a 16-bit address bus, because that's just the way I think and it makes things easier to explain; things would be a bit different in the case of a mainframe computer, but the overall concept remains sound):
Typical machine-code implementation of our example program statement.
In this example, the first instruction is a LOAD, which loads the accumulator (ACC) using the "absolute" addressing mode (the absolute address of the data in memory is provided in the memory locations following the opcode). The second instruction is an ADD using the "immediate" addressing mode, which means the value to be added to the contents of the accumulator (the binary equivalent of "2" in this case) is provided in the memory location immediately following the opcode. Finally, the third instruction is a STORE, which copies the contents of the accumulator (ACC) back into memory using the absolute addressing mode (once again, the absolute address of the data in memory is provided in the memory locations following the opcode).
To Page 2 >