In 1959-60, We Thought We Were Ahead of the Curve
Delta was the internal code name for our Commercial Computer Development Program (CCDP) in my first company. We proceeded in quiet and determined isolation behind our security fences and guards to design a multiple-level computer system that would outperform the entire competition. We needed an overall architecture for the system, a set of design objectives, and several technology objectives to meet the architecture. There were a number of objectives from the start that helped to drive the architecture and the design:
First, we wanted the design to be able to incorporate new technologies easily, since solid-state circuitry was rapidly progressing, and we didn’t want our system architecture to be outmoded soon after its introduction.
The biggest problem was memory, and we knew we would need a larger sized memory than we had been accustomed to: all of 64,000 words of 32 or 36 bits. There was a significant cost difference between 32 and 36 bit memories, and the then magnetic core elements strung together were not easy to produce cheaply.
Plus, we wanted memory to be partitioned into 8K blocks of words. Also the size of a byte (in today’s terms) was a debate on the team: any of the 4-bit, 6-bit, or 8-bit representations of characters and marks were considered possible to design into the unit. We settled on the 4, 6, and 8-bit bytes, and a 36-bit word. This meant we had words of 9 x 4-bit characters, 6 x 6-bit characters, or 4 x 8-bit characters for data. The memory busses had to carry the full 36-bit words, obviously.
What drove us to the 36-bit word was the need for floating point words with a characteristic and mantissa of sufficient width that the accuracy of computation would be excellent, together with the need for each “pull” from memory to result in as much data available to the processors as possible. A final reason was the control logic and control points for the operation of the whole system. The wider the instruction word, the faster the layers of control could be driven, and the larger the capacity could be for direct addressing.
We also built in what we called multiplexing addresses, either two-way, four-way or eight-way. For example, in the two-way case, the addresses would alter between the two modules, even and odd. This allowed simultaneous pulls from every memory, delayed by the access time for the banks.
We then decided that memory could be banked in modules of 8K words of 36 bits, with 8 modules the physical limit because of propagation delays between these large elements. A lot of experimentation was done to assure that we could bus these units at a very high pulse rate.
Early on, we decided to totally separate the computing unit from the input/output logic, and that turned out to be a good idea all around. The “input/output unit” ended up being the lowest level processor of the line: Delta 1. (A year later, I saw that the I/O-Compute architecture was a common design.)
We then decided that the computing unit should be divided as well between basic arithmetic and comparison logic and routines and floating point logic and routines. This could be used to speed up repetitive sequences of instructions such as in a matrix inversion. (This is now known as look-ahead logic, I believe.) Also, for the lower level processor, we could omit the hardware floating point unit and do the execution with software.
Meanwhile we had been developing our CPU and I/O instruction sets. We had the brilliant idea that we should develop the instruction set on another computer by simulating the logical execution of each instruction. So the Delta instructions were developed on an IBM 704. This effort was only partially completed in the year we had been given. All of the key instructions had been simulated, and just about every control step had been identified, so it would be easy to finish off the remainder later. ( This was standard practice in IBM/FSD later on, as I would discover.)
One innovation we thought was clever was the instruction code execution logic. The instruction code was used to access a very high-speed memory unit that was 128-bits wide. Most of the bits were direct controls sent to control points. To change an instruction was simply to change its 128-bit word sequence and interpretation in that memory. (Oh dear! Again, I found out about the "bump memory" in IBM 7040 and 7090 architectures when I joined that company. This was a frustrating revelation!)
So Delta 3 had a maximum of 8 Memory units, an I/O unit, an Arithmetic unit, and a Floating-point unit, all connected by a wideband bus. We had the idea too that we could put more processors onto the bus if we could share the processing load between them.
Many other details of this program I have omitted here, mainly because they are not very interesting…to me, anyway! ( One element, however, haunted me all the way, and that was software! We had a basic set, but it was infantile compared to what IBM could deliver,)
Parenthetically, perhaps in 1964 or 65, I saw the exact same architecture being implemented by IBM using IBM 360-50s for the FAA Enroute Control Centers. If I remember correctly, they had named this system the IBM 7050 (or was it 7020, my memory fails me?) Of course, the 360 instruction set was different, and the speed of the Model 50 was less than Delta would have been. Some years further on, the 50s were replaced with 360-65s in a cluster configuration.
It was then, after I had been in IBM/Federal Systems Division for almost 5 years, that I felt completely satisfied that the Delta design had been sound and viable, and indeed ahead of its time.
PS. This post is a personal memory of an exciting project. You must indulge me this!
# posted by Mannning @ 1:45 AM
Post a Comment