Two-address systems: IBM System/360 and /370

The design objectives for the IBM System/360 (introduced in 1964) [1], were very different from those for the CDC 6600 (described under Three Address Systems). IBM's intention was to produce a line of processors (initially six) with compatible order codes, but a performance range factor of 50. Furthermore, whereas the CDC 6600 was intended specifically for scientific and technological work, System/360 machines were required to be configurable for a variety of tasks covering both scientific and data processing applications. The former are dominated by floating-point operations, where fast access to intermediate values requires the provision of one or more registers close to the arithmetic unit(s) in the central processor. Data processing applications, on the other hand, frequently involve the movement (and fairly simple manipulation) of long strings of data, and direct two-address storage to storage operations are much more appropriate than operations involving three store addresses or operations involving the use of intermediate values held in registers. Furthermore, in machines at the low performance end of the range, logical registers are normally implemented within main storage, and the extra store accesses required for these registers would actually slow down this type of operation.

Store addressing is itself a major problem in the design of a compatible range of computers; to quote from IBM, in turn quoting from DEC [1], [2]

"There is only one mistake ... that is difficult to recover from - not providing enough address bits ..."

In the design of the IBM System/360 large models were seen to require storage capacities of the order of millions of characters, whereas small models required short addresses in order to minimise code space requirements and instruction access time. This problem was overcome by the use of index registers to supply base addresses covering the entire 24-bit address space, and small displacement addresses within instructions. This can be seen in the figure, which shows the five basic instruction formats: register to register operations (RR), register to indexed storage operations (RX), register to storage operations (RS), storage and immediate operand operations (SI), and storage to storage operations (SS). All operand addresses consist of a 4-bit B field specifying which of the 16 general registers provided is to be used as a base value to form the store address. In the case of the RX format, a further general register is specified by the X field, for use as a conventional index register allowing access to an element within an array, for example. In the RS format this field becomes R3, used in the specification of the number of registers involved in the simultaneous transfer of a multiplicity of register contents to or from store. A typical instruction using the RR format, for example, involves the addition of the content of the register specified by R2 to the content of register R1, the result being returned to R1.

IBM 360 instruction format

Figure 3. IBM 360 instruction format

The number of registers to be provided was determined from an extrapolation, at the time when the System/360 was designed, of contemporary technological trends. These indicated the probable availability of small high-speed storage devices, and the design therefore incorporated what was then considered to be a substantial number of logically identifiable registers. These registers were to be physically realised in core storage, local high-speed storage or discrete transistors, according to the model. There are, in fact, two sets of addressable registers, sixteen 32-bit general purpose registers used both as index registers and fixed-point accumulators, and four 64-bit floating-point registers. Both sets occupy the same logical address space, the operation code determining which type of register is to be used in a given operation. The choice of 16 addressable register locations also allows the specification of two registers in a single 8-bit byte, the smallest addressable unit of information in the System/360. The separation of the two sets, using operation code information, allows instruction execution in larger models to be carried out in a separate unit from, and concurrently with, the preparation of subsequent instructions, thus leading to higher performance. Further details can be found under Parallel Units.

Store addresses generated by the central processor of almost all System/360 machines are real addresses, each referring directly to a physical location in main store. (The same is also true of CDC 6600 addresses.) A move away from this situation occurred with the introduction of the System/370 in 1970 [3]. IBM System/370 machines have essentially the same order code as System/360 machines, with minor modifications including, for example, the introduction of some one-address instructions. Addresses in System/370 machines are all virtual addresses, however, which do not refer directly to physical locations in the main store, but are mapped on to these locations by a dynamic address translation mechanism. Such a system was first introduced in Atlas, details of which can be found under Stores.

References

  1. ^ G.M. Amdahl and G.A. Blaauw and F.P. Brooks
    "Architecture of the IBM System/360"
    IBM Journal of R & D, Vol 8, pp 87-101, 1964
  2. ^ R.P. Case and A. Padegs
    "Architecture of the IBM System/370"
    CACM, Vol 21, pp 73-96, 1978
  3. ^ .G. Bell and W.D. Strecker
    "Computer Structures: What we have learned from the PDP-11"
    Proc. 3rd International Symposium on Computer Architecture, pp 1-14 1976
Return to Instructions and Addresses