-----------------------------------------------------------------------------------------------------------
A. Padegs - System/360 and Beyond
The evolution of modern large-scale computer architecture within IBM is described, starting with the announcement of Systeml360 in 1964 and covering the latest extensions to System/370.
Emphasis is placed on key attributes and on the motivation for providing them, and an assessment is made of the experience gained in the implementation and use of the architecture.
The main approaches are discussed for obtaining implementations at widely differing performance levels, and a number of significant implementation parameters for all processors are listed.
Emphasis is placed on key attributes and on the motivation for providing them, and an assessment is made of the experience gained in the implementation and use of the architecture.
The main approaches are discussed for obtaining implementations at widely differing performance levels, and a number of significant implementation parameters for all processors are listed.
Introduction
With the introduction of Systein/3W in 1964, a major
change in the development of computers within IBM took
place. With the recognition that architecture [1] and
implementation could be separated and that one need not
imply the other, a common machine architecture was
established. It was intended for program-compatible embodiments
over a wide range of performance levels and
for various types of applications.
Since its introduction, this architecture has been the
basis for all intermediate and large computers produced
by IBM. It has also become the basis for machines
produced by a number of other manufacturers in the
USA, Japan, and the Soviet Union. The architecture has
provided a firm interface for application development,
and it has permitted the operating systems to grow
significantly in size and function. Although the architecture
was developed when logic technology with a single
device per chip and magnetic cores were used to implement
machines, its fundamental structure is still suitable
for today's designs, which use dense arrays and integrated
circuits of thousands of elements per chip.
This paper reviews the salient characteristics of the
System/360 architecture and its follow-on, the System/
370 architecture. The objectives are to cover significant
accomplishments, to give the motivation for key architectural
decisions, and to present an assessment; it is not
intended that the paper provide a complete historical
record of IBM's architecture developments. Furthermore,
the paper does not contain a detailed technical
review of design considerations and alternatives; this
type of review has been published previously [2-9],
The first two sections review the System/360 and
System/370 architectures, stating the objectives, constraints,
and contributions. Following this, developments
in I/O architecture are outlined. The introduction of
various enhancements to the architecture is discussed in
relation to product announcements; and, in a separate
section, the significance of microprogramming and the
cache to the implementation of a compatible Une of
machines is reviewed. The final sections are devoted to
an assessment of IBM's experience with System/3W and
System/370. In an appendix, tables comparing implementation
characteristics for all processors provide further
illustration of the steps taken to achieve different performance
levels.
Systetn/360 architecture
System/360 was the result of a major effort to design an
architecture for a new fine of computers that was unencumbered
by the requirement to be compatible with
existing architectures. Work on a new architecture for a
family of machines began in the early 1960s; its specifications
were released in April 1964, when the first models of
System/360 were announced.
When System/360 development was initiated, most
new computer models were, from the viewpoint of their
logical structure, improved, enlarged, or technologically
recast versions of the machines developed in the early
Copyright 1981 by International Business Machines Corporation. Copying is permitted without payment of royalty provided that (1)
each reproduction is done without alteration and (2) the Journal reference and IBM copyright notice are included on thefirst page.
The title and abstract may be used without further permission in computer-based and other information-service systems. Permission
to republish other excerpts should be obtainedfrom the Editor.
IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SBPTEMBER 1« 1
1950s. IBM products had evolved from 701 to 7094 II,
from 702 to 7080, from 650 to 7074, and from 1401 to 7010
[10]. Additionally, IBM had produced Stretch, formally
known as the IBM 7030; it had been developed largely as
a project to challenge the state of the art, but from the
point of view of architecture it was a predecessor of
System/360.
In many ways the design concepts underlying System/
360 [2-5] were the same as those for Stretch [11]. Both
Stretch and System/360 provided, in a single architecture,
facilities suitable for scientific, commercial, and real-time
applications; both placed major emphasis on the generality
and code-independence of instruction and data formats;
and both provided for the uniform attachment and
control of a wide variety of I/O equipment. System/360,
however, was the first demonstration that the concept of
developing an architecture for a family of compatible
machines was practical, with the initial implementations
targeted to yield models with internal performances ranging
from that of the IBM 1401 to well beyond that of
Stretch. Intermodel compatibility was probably the most
far-reaching requirement in developing System/360 and
one which affected both the architecture and the procedures
for developing and controlling it.
System/360 incorporated a number of the new architecture
concepts introduced in Stretch, such as binary
storage subdivision and the eight-bit byte, storage protection,
and a generalized interruption mechanism. However,
the System/360 architectural definition of some of
these concepts differed from that in Stretch because the
environment and objectives were different. Since Stretch
had the flavor of an experimental computer, its architecture
could afford to strive for a set of functions of great
logical consistency and completeness. System/360, on the
other hand, was defined at its inception as a base for a
product line. As such, its development called for a more
frugal choice in the selection of functions, based on a
critical evaluation of the available experience. The architecture
had to encompass implementations covering wide
performance and cost ranges, and its definition had to
reflect compromises between the performance and cost
objectives of large and small machines. As a result.
Stretch innovations such as storage addressing to the bit
level, variable byte size, and automatic handling of floating-
point range exceptions were not included.
The following are the key areas where System/360
introduced innovations or otherwise determined direction
in architecture.
Addressing For efficiency and because of the ease of
table utilization, System/360 uses binary-radix storage
addressing, with 24-bit addresses that designate byte
locations. Thus System/360 can address 16M eight-bit
bytes, as compared to the 2M bytes on Stretch (M stands
for 2^" or 1 048 576). This addressing capability is, of
course, available on all models and should be considered
in light of the maximum storage sizes available at that
time: 32K 36-bit words on the 7094II (K stands for 2'" or
1024), 160 000 six-bit characters on the 7080, 300 000
digits on the 7074, 100 000 seven-bit characters on the
7010, and 16 000 seven-bit characters on the 1460 (the
word-mark bit is included in the 7010 and 1460 character
sizes). The smallest initial System/360 model. Model 30,
offered up to 64K eight-bit bytes, and IM bytes was
available on the largest initial model. Model 75. The
ability to address and to effectively utilize large storage
was one of the key attributes of System/360.
Address generation A truncated 12-bit address in an
instruction, in conjunction with a full base-address value
in a register, provides indexing and eliminates the inefficiency
of carrying a full address in each instruction. A
second level of indexing is available in some instructions
to facilitate loop control. The 12-bit displacement, without
an index or base value, provides addressability for
loading or saving the base values but normally is so small
that all programs need base addresses and are thus
generally location-independent.
Provision for control program A comprehensive interruption
system, supervisor and problem states, storage
protection, and an interval timer provide a basis for
designing a secure operating system. Input/output instructions
are invalid in the problem state, and means are
provided for the supervisor to control the duration of
application programs and switching between them. (In
Stretch an operating system could be modified by unauthorized
input from an I/O device.)
Input and output The multiplexer channel and a common
method of attaching and programming all I/O devices
extended the concepts introduced in 702 and Stretch.
These aspects are discussed subsequently in the section
"Input and Output."
General-purpose registers Sixteen registers serve as
accumulators for fixed-point and logical operations, as
well as sources of base and index values in address
generation, thus bringing the full power of the fixed-point
arithmetic-operation set to bear upon indexing computations.
Character size In contrast to the straight six-bit approach
used in the IBM 702-7080 and 1401-7010 families,
two character sizes were introduced: eight-bit codes for
alphanumeric, and four-bit codes for numeric characters
This approach, used in the IBM 650-7074 family, has
IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
greater coding efficiency, with spare code points in the
alphabetic set, and is commensurate with binary subdivisions
used in the rest of the system. The length of
operands is specified in the instruction: Decimal operands
can be up to 16 bytes in length; character operands are
variable up to 256 bytes. In Stretch any character size
from one to eight bits could be specified, but variablefield-
length operands were limited to 64 bits.
Floating-point data format Two formats were introduced,
both available on all models: a 64-bit format for
use in precision-sensitive problems and a 32-bit format for
faster speed and conservation of storage space. The 32-bit
format was intended primarily for the smaller models,
where differences in the execution time for the two
formats were significant. The alternative would have
been a single 48-bit format to succeed the 36-bit format of
the 7094 and the 64-bit format of Stretch. Both the 32-bit
and 64-bit formats use the same exponent size, with a
base of 16. This was a departure from base 2 and was
introduced to permit simpler circuitry and to reduce the
frequency of pre-shift, overflow, and precision-loss post-
shift in addition and subtraction [12].
Serviceability The ability to automatically record the
detailed machine state at the instant of an error and to
initialize it to any specified value provides tools for
significant serviceability improvements [13].
The models at both ends of the performance range
introduced architecture changes to meet their particular
cost and performance goals. Model 20, although nominally
called part of the System/360 family, was incompatible
with System/360. Its architecture provided for a maximum
main storage of 64K bytes, and it had 37 instead of
System/360's 143 instructions. Other differences were
that it did not include the supervisor state, had its own set
of I/O instructions, and had a 32-bit instead of the 64-bit
program-status word (PSW). Compatibility for running
application programs was affected because the Model 20
omitted floating-point and 32-bit binary arithmetic, had
eight 16-bit instead of sixteen 32-bit general registers, and
had a special direct-addressing mode for forming storage-
operand addresses.
At the other end of the performance range, the Models
91, 95, and 195 introduced some deviations to accommodate
their highly overlapped designs by delaying program
interruptions and permitting the result of a divide operation
to be off by one bit in the low-order bit position.
These differences required some adjustments in software
but did not affect compatibility for application programs
in any significant way.
Additional functions were introduced by a few of the
later System/360 models. Model 44, announced in 1965,
IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
had a number of extensions for real-time applications,
which, however, were not continued in later models. At
the same time. Model 67 introduced virtual storage [14],
which, with some modifications, became a basic part of
System/370. The 9020 System, which was developed for
the Federal Aviation Administration, interconnected
modified Model 50s into a multiprocessing system to meet
exceptionally stringent requirements for continuity in
machine operations [15]. Models 65 and 67 both offered
multiprocessing facilities [6], which later were significantly
extended for System/370.
Then, in 1%8, as part of the extended-precision floating-
point facility on the Model 85, the 128-bit floatingpoint
format was introduced [7]. The package also included
special instructions for rounding floating-point numbers
when going to a shorter format; they aUeviated
somewhat the lack of rounding in the original architecture.
Model 85 also removed the original System/360
requirement that storage operands for unprivileged instructions
be aligned on boundaries equal to a multiple of
the operand length. Both of these extensions were carried
into System/370. Additionally, the 2880 Block-Multiplexer
Channel, on System/360 Models 85 and 195, had many
of the System/370 I/O architecture extensions [8].
In two areas the original System/360 decisions on user-
oriented functions were subsequently changed. The first
one concerns floating-point instructions. The original
System/360 architecture did not anticipate the significance
of compatibility in the handling of overflow and the
need for indicating the true result value on both overflow
and underflow. Furthermore, it had overlooked the need
for a guard digit in post-normalization. Both of these
functions were changed in 1968, with all installed machines
retrofitted.
The other change concerns the encoding of decimal
data. System/360 anticipated the adoption of a proposal
for a seven-bit American Standard Code for Information
Interchange (ASCII) and of a technique for expanding the
seven-bit code to eight bits. It provided a mode bit in the
PSW that specified, for the code-sensitive instructions,
operation with either the ASCII or the Extended-BinaryCoded-
Decimal-Interchange Code (EBCDIC). The eight-
bit extension of the code was never adopted as a national
standard, and the ASCII mode has subsequently been
deleted in the System/370 architecture. It was highly
unUkely that any production programs ever used the
eight-bit ASCII code; none have ever been identified. The
mode bit subsequently turned out to be the only unassigned
one in the PSW and was convenient for distinguishing
between the original and the extended-control
(EC)-mode PSW format introduced for System/370.
In a number of other areas, different architectural
choices, in retrospect, might have been preferable. The
problem of storage-address size is discussed later in the
paper. For some areas, extensions have subsequently
been introduced to solve the constraints set by the initial
decisions; for example, the new EC-mode PSW format
corrected the lack of extensibility in the original PSW
format, and the early release of the CPU during execution
of the new System/370 START I/O FAST RELEASE instruction
eliminated the unnecessary delay required by the original
START I/O in high-performance machines. In other areas,
the need to preserve compatibility has been felt to be so
overwhelming that the reevaluation of the original architectural
choices has been of no practical interest. This
applies particularly to problem-program functions, such
as whether the floating-point significance exception is
really useful, and whether the EDIT and EDIT AND MARK
instructions are warranted in view of their very specific
operand formats.
Systemn/370 architecture
In contrast to System/360, the objective of System/370
was an evolutionary extension of System/360 architecture
for a new set of models and for new releases of programming
systems [9]. Experience with the System/360 architecture
had identified a number of bottlenecks and Umitations
in the efficiency of system use and had pointed out
areas where additional machine functions were desirable.
Furthermore, because the cost of technology for main
storage and logic circuitry was becoming lower in relation
to the overall system cost, it was feasible to consider
extending the machine architecture; it was possible, in
fact, to economically include functions that did not appear
justified when System/360 was developed. For example,
because of cost considerations in the smaller
models, System/360 provided only one 32-bit timer in a
main-storage location, which had to be programmed to
provide all timing functions. System/370 introduced three
distinct facilities, each with a 64-bit value: a time-of-day
clock (for real-time indication), a clock comparator (a
real-time alarm clock), and a CPU timer (for measuring
process time) [9].
System/370 was constrained to be upward-compatible
for System/360 application programs and for the main-line
operating systems. Even though such operating systems
could not benefit from the new functions available in
System/370, and new support was planned, the ability to
run those operating systems was needed for the transition
period. For this reason, System/370 continued to provide
functions, such as the System/360 timer and the System/
360 PSW format, that had in fact been superseded by
functionally richer extensions. Additionally, System/370
needed to attach and operate System/360 I/O devices.
System/370 evolved, and its architecture [16] was released,
in a number of increments. The system was
introduced in June 1970 with the announcement of Models
155 and 165, at which time the main architectural
extensions were six general-purpose instructions, the
time-of-day clock (with a period of 143 years and a
resolution of one microsecond), and control registers
(they serve as an extension of the PSW). The original
System/370 also included a number of extensions to
enhance model-independent recovery by software from
machine malfunctions [17]. Virtual storage, the CPU
timer, the clock comparator, program-event recording
(for software debugging), and the new PSW format and
interruption controls associated with the extended-control
(EC) mode were introduced with the announcement
of Models 158 and 168 in August 1972. Multiprocessing
and the conditional-swapping and PSW-key-handling instructions
were introduced in February 1973.
Then, with the introduction of the 3033, a number of
extensions were made available that enhanced the performance
and function of the MVS operating system.
One-level addressing and the instruction MOVE INVERSE
were introduced as part of the VSE (virtual storage
extended) mode on the 4300 processors to meet the needs
of the DOS/VSE operating system [18, 19]. The MOVE
INVERSE instruction is intended primarily for environments,
such as the Arabic language, where text is arranged
in a right-to-left order.
The single item that most distinguishes System/370
from System/360 is the availability of a dynamic-addresstranslation
facility, which allows the control program to
efficiently implement a group of functions collectively
referred to as virtual storage. The approach incorporates
paging from external storage as introduced in Atlas [20]
and a second level of indirection, segmentation, as suggested
by Dennis [21] and as further detailed by Arden et
al. [22].
The System/370 version of this facility is largely patterned
after the System/360 Model 67 [14]. Experience
with that machine and its operating system, TSS, had
verified the value of many of its concepts and had
provided actual usage data for making System/370 design
decisions. In addition to a number of format changes,
System/370 offers two page and segment sizes to accommodate
both large and small systems, but it does not oflfer
32-bit virtual addressing, which was available on the
Model 67. The System/370 virtual-storage operating systems
were evolutions of the corresponding real-storage
operating systems and could not accommodate 32-bit
addresses.
A. PADEGS IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
The virtual-storage architecture of the 3033 and other
large processors was enhanced early in 1981 by the
introduction of the dual-address-space facility. This extension
includes a 16-bJt address-space number, which is
associated with a set of segment and page tables and
identifies a virtual address space of 2 " bytes. A total of
2'* address spaces can be established, although at any one
time addressability exists to two address spaces—the
primary and secondary. Instructions and controls are
provided to load an address-space number so as to
establish addressability, call and return from programs in
either the same or another space, move data between
spaces, and establish authorization for these operations.
These facilities extend the size of the addressable virtual
storage and provide a basis for enhancing system integrity.
In the VSE mode, the main change was the substitution
of the one-level-addressing facility for the System/370
dynamic-address-translation facility. DOSA'^SE offers
one virtual address space of up to 16M bytes, and the
architecture is simplified accordingly by eliminating the
multiple-address-space capability of the System/370.
Storage is directly addressable by the CPU and all
channels, using a uniform set of virtual addresses. The
translation table is in internal machine storage, and
special instructions are provided for setting up the mapping.
Protection, by means of storage keys, applies to
virtual instead of real storage. Because of the simpler
translation procedure and the ability of channels to use
virtual addresses, performance gains are possible, and the
software for translating addresses in channel programs is
eliminated. The VSE mode is compatible with System/
370 for problem programs, but not for the control program.
The full System/370 facilities are available on the
4300 processors in the System/370 mode.
Another major fimctional extension is the inclusion of a
number of facilities that permit formation of a multiprocessing
system, where two or more CPUs share common
main storage and are controlled by a single copy of the
operating system. The concept of using a prefix to offset
the main-storage address when accessing the block containing
shared control information is the same as that
used in System/3W). The architecture was extended,
however, by making the prefix settable by the program
(instead of manually) and by providing the SIGNAL PROCESSOR
instruction and a special interface for communicating
between CPUs. On the 3033 a further extension
made it possible for the software to connect a set of
channels to one of two CPUs.
The main extension to the multiprocessing architecture,
though, was in the control of accesses to shared
main storage. In a multiprocessing system, the conventions
of a uniprocessor communication protocol become
inadequate when one CPU is changing the contents of a
common storage location while the other is observing it,
or when both CPUs are updating the contents of the
location at the same time. The System/370 architecture
includes a number of rules on the concurrency, multipMcity,
and order of storage accesses, and specific instructions
are introduced to permit sharing of serially reusable
resources, such as updating chained lists. Specifically, in
System/360, the TEST AND SET instruction provided a
means whereby the inspection of a bit in storage and the
setting of it to one could be performed indivisibly. In
Systeni/370, the two compare-and-swap instructions indivisibly
compare afield in storage with a value in a register
and, upon matching, replace the storage operand with a
new value [16].
The IBM System/370 Principles of Operation [16] in the
Spring 1981 edition contained a total of 204 instructions,
as compared to the 143 initially available in System/360
[23]; this provides one indication of the growth of the
architecture. Of the 61 new instructions, 39 are either
privileged or semiprivileged {11 of the original System/360
instructions were privileged), indicating that a relatively
larger portion of the architectural extensions is intended
for system functions.
input and output
The concept of a common method of I/O attachment and
control evolved gradually. The 702 had a common interface
for attaching I/O control units and a common architecture
for controlling I/O operations. The 709 introduced
the concept of a channel. The Stretch "exchange" [10]
provided a mechanism for sharing equipment for multiple
I/O operations, using a common I/O interface and I/O
•architecture (a different interface was used for attaching
the disk unit to the high-speed exchange, and the instructions
for its control differed somewhat). In 1961 a standard
Interface was established for attaching I/O to all new
large systems. It was a modification of the Stretch
interface and was available on the IBM 1410/7010, 7040/
44, 7070/74, 7080, and 7090/7094 systems for attaching
disk, magnetic tape, and communications control units.
System/360 extended the standardization of I/O attachment
and control by applying a common attachment
interface and a uniform program control to a larger
variety of device types and covering a wider spread of
data rates.
* Channels
System/360 introduced the subchannel, which for most
purposes gives the appearance of an independently oper-
A. PADEGS
ating processor that can sustain its own channel program.
Different types of channels were designed, and, depending
on the type of channel, different levels of concurrency
among channel programs were made possible. A selector
channel has one subchannel and permits operation with
one device at a time, normally at a high data rate. A
multiplexer channel can have up to 256 subchannels and,
conceptually, can be executing a channel program for
each subchannel. The actual level of interleaving depends
on the type of multiplexer channel and the device. A byte-
multiplexer channel is designed for low-speed operation
to interleave individual bytes or bursts of bytes from such
devices as keyboards, communications lines, printers,
and card equipment. When it was introduced, it represented
a major advance for communications-based systems
and real-time applications [5]. The block-multiplexer
channel, introduced later for Sy8tem/36p Model 85, is
intended for high-speed operation and is particularly
advantageous for use with rotating storage devices, such
as disks and drums [8]. When used in conjunction with
rotational-position sensing, it permits a subchannel to be
assigned and a channel program to be estabhshed for each
access arm, with each program monopolizing the channel
for the duration of data transfer but releasing channel
facilities during arm movement and during the rotational
delay associated with locating the designated record.
• 110 interface
The System/360 I/O interface is the connection between a
channel and an I/O control unit; it provides the necessary
physical, electrical, and communications-protocol specifications.
It is based on the standard interface of 1961.
The original Systeni/360 I/O interface specification was
adequate for data rates up to about IM bytes per second
for a cable length of about 100 feet. For cable length of the
order of 20 feet, the IBM 2301 Drum Storage, with a rate
of 1.2M bytes per second, could be accommodated. The
ftiUy interlocked signaling protocol allowed one channel-
cable connection to sustain data transfer over a very wide
range of rates, with both the channel and device having
complete control of the timing of each byte transfer. It
did, however, require an electrical signal to be propagated
between the channel and the control unit four times for
each byte transferred.
With the advent of auxiliary-storage technologies employing
higher recording densities, it was necessary to
increase the data-transfer capacity of the interface. For
some buffered devices a higher data rate was desirable to
reduce the transfer time. Furthermore, many installations
needed longer cable connections. To meet these goals,
System/370 introduced changes both in the signaling
protocol and in the width of the interface.
The System/370 I/O interface [24] includes two additional
tag lines to provide the same level of transfer
interlocks with only two propagation times per byte
transferred. It depends on the control unit whether or not
the new facility is used; thus, control units implemented
to operate with the System/360 protocols can be attached
to System/370 channels. On some System/370 channels
and control units the bus width can be extended optionally
to two bytes, thus doubling its datk-transfer capacity.
As a result of these two additions, the System/370 I/O
interface can sustain a data-transfer rate of over 1.5M
bytes per second in the one-byte version and over 3M
bytes per second in the two-byte version, over a cable
length somewhat less than 100 feet; longer distances can
be accommodated at lower data rates.
The data-streaming mode, introduced recently for the
IBM 3380 Disk Storage, eliminates the interlocks between
the request and response signals during data transfer.
Data, with the appropriate tag signals, are sent in the
form offixed-length pulses. This eliminates the dependency
of the data rate on cable length caused by the interface
protocol. The IBM 3380 specifications provide for a
transfer rate of 3M bytes per second over 400 feet with
the one-byte interface.
System/360 was the first system in which a common
attachment interface was used to connect a large variety
of I/O control units to a line of computers. The interface
has been successful in a number of ways. It has offered an
unprecedented choice of I/O equipment in configuring a
system. It has permitted channels and control units to be
designed independently and at different locations with an
assurance that, assembled into a system on the user's
premises, they will operate without any adjustments.
Furthermore, the specific interface definition has been
sufficiently general and flexible to accommodate new
device types and to permit extension offlinction and data
rates in a compatible manner. As a result, a control unit
designed to the original definition (after the 1967 change
to the electrical specifications) can operate with a channel
incorporating the latest extensions, provided the channel
meets the speed requirements.
The standard interface permits other attachment approaches.
At the penalty of losing some configuration
flexibility, the total cost of a system can be reduced by
eliminating a separate frame and power supply for the
control unit, by eliminating the use of an interface cable
and the associated drivers and receivers, and by sharing
some main-frame logic circuits for the control-unit functions.
Such integrated designs are offered on the smaller
System/360 and System/370 models for some common I/O
device types. Even though such designs physically merge
IBM } . RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
the channel and control unit, they nevertheless maintain
the logical separation and simulate those aspects of the
standard interface that are observable by the program.
Thus, regardless of the implementation, all I/O devices
are controlled by the same set of I/O instructions, command
words, and other program formats.
Implementation approaches
The various levels of performance and cost in the implementation
of the architecture are achieved by appropriate
choices and tradeoflFs among such parameters as circuit
speed and cycle time, width of data and logic paths,
overlap of instruction execution, and speed, width, and
interleaving of main storage [25, 26]. Two new developments
in machine implementation, however, are particularly
significant in the adoption and subsequent extension
of System/360 architecture: microprogramming and the
cache (high-speed buffer).
• Microprogramming
Microprogramming, originally suggested by Wilkes [27],
is the use of simple and fast low-level instructions for
controlling machine sequences [28-30]. This type of design
permits sharing a basic dataflow for a wide variety of
functions and readily permits tradeoflFs between cost and
performance. With conventional logic circuitry, the cost
of controls increases in a roughly linear relationship to the
functional capability. With microprogramming, a base
cost for the microcode-storage device and the supporting
logic must be borne, after which the incremental cost for
adding more storage in order to microprogram additional
function is relatively small.
It was largely because of microprogramming and the
economy associated with sharing hardware that it became
economically feasible to implement the full System/360
architecture on the smaller models. The savings were
particularly significant in the implementation of input and
output, as microprogramming made it possible to build
integrated channels where the logic capability of the
machine is time-shared between CPU and channel functions.
In such an implementation, the channel becomes a
conceptual entity, and one may include a large number of
subchannels at virtually no cost other than the storage
space for the governing control information.
Microprogramming made it possible to incorporate in
System/360 and System/370 models the capabilities for
emulating other architectures, such as those of the IBM
1401 and the IBM 7094 [31]. It also made it possible to
extend the original System/360 architecture with assists
for specific operating systems. Furthermore, microprogramming
has had a beneficial effect on the architecture-
resolution process, since it permits corrections and
changes in machine functions after the circuitry has been
designed and built; some changes are feasible even after
the machine has been delivered to the customer.
Microprogramming is used to varying extent in all
System/360 and System/370 models except for Models 44,
75, 91, 95, and 195. The extent and the method of use
depend on performance objectives. Larger models normally
have more bits per microprogram-instruction word
for the control of their more complex data paths. On the
other hand, smaller models have larger microprograms,
since these models require more cycles to accompUsh the
same function and use microprogramming for more functions.
As an example, the Model 168 has 4K words of 108
bits each, whereas the Model 138 has 64K words of 18
bits each. In the initial System/360 models, microprograms
resided in read-only storage, but in most later
models read-write storage is used. In the smaller models,
microprograms reside in an extension of main storage.
• Cache
Starting with System/360 Model 85, the larger models use
a high-speed buffer, called the cache, for accesses to main
storage. Although the concept had been considered previously
[32], IBM was the first to implement a large cache
in a commercial computer [33-36]. The cache was a major
advance in system organization and subsequently has
been extensively analyzed in the literature [37-39]. The
cache is interposed between the CPU and main storage,
and its existence is not apparent to the program.
The cache reduces the number of main-storage references,
because information fetched into the cache can be
reused without access to main storage. Furthermore, by
loading entire "Knes" (typically 32-64 bytes) on any
request for storage information, the machine can prefetch
valuable information for future use and thus avoid the
delay associated with additional storage access. The
effectiveness of the cache depends on its size and other
design parameters, as well as on the distribution of
addresses used to access storage. According to Liptay
[34], on the Model 85 with a 16K-byte cache, typically
97% of fetches were satisfied with data from the cache.
With larger caches, in scientific applications "hit" ratios
of 99% and over can be attained, although for interactive
environments a more typical ratio is 96%. Furthermore,
by allowing channels to communicate directly with main
storage, the cache reduces storage interference and improves
accessibility of storage for I/O, thus permitting
higher I/O data rates.
The effect of a storage hierarchy using a cache is to
reduce the dependence of CPU operations on storage
access time and to provide a better match between the
IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981 A. PADEGS
operation speeds of main storage and CPU circuitry. The
cache provides more freedom in the choice of storage
technologies and allows for larger storage and longer
access times. The introduction of a cache played a
significant role in the realization of systems with large
main storage.
Experience with System/360 and its extensions
The following are some of the major observations to be
made and conclusions to be drawn concerning System/360 and its extensions.
• Implementation of compatible machines
Experience clearly verified that the initial System/360
goals for a compatible line of machines were realistic, and
that it was feasible to build a family of machines within
which programs could be transferred routinely from one
model to another. The validity of the original compatibility
goals was particularly proven by the fact that other
manufacturers have been successful in producing System/
370-compatible machines. In fact, compatibility helped
reduce development costs within IBM. The original System/
360 plan called for verifying each element of software
on each model. Because of the growing confidence that
programs which ran on one model would also run on
other models, it was possible to significantly reduce the
amount of cross-verification performed.
The original System/360 announcement included processors
with a performance range of 25 to 1. Six years
later this had increased to around 200 to 1, and today the
performance of the 3081 is approximately 450 times that
of the System/360 Model 25.
• Main storage
Main-storage sizes grew more rapidly than was anticipated
in the 1960s; the technological improvements, which
reduced the cost, had occurred at a faster rate than was
expected. Thus, it became obvious at the time System/
370 was in the planning stages that the 24-bit main-storage
address size would have to be extended eventually.
The extension of the address size, however, proved to
be more difficult than first expected. The basic addressing
mechanism of System/360 was well suited to extension,
since it depended on base registers that were already 32
bits wide. The interruption mechanism and the I/O control
formats, however, did not have the required extensibility,
since immediate cost and performance consequences
in 1962 had outweighed the need to meet eventual
long-term requirements. More importantly, operating
systems and compiler-produced application programs had
used the extra bit positions in address words for control
purposes and hence required extensive modification.
In all new formats introduced for System/370, such as
the control registers and the EC-mode PSW, main-storage-
address fields are assigned 32 bit positions, should
they be needed for address expansion. On the 3033 and
other large machines, however, real storage in excess of
16M bytes is accommodated by making use of unused bit
positions in the translation tables.
• Precision vs. unpredictability
In. order to ensure compatible implementations, the architecture
has to be complete in that it must cover all
functions of the machine that are observable by the
program, including all the unlikely concurrent occurrences
of different unusual exceptions. It either must
specify the action the machine performs or state that the
action is unpredictable.
Identical action in all machines is less likely to cause
problems with compatibility and has a certain aesthetic
appeal. Indiscriminately specifying predictable operation,
however, may present problems when the predictable
operation is of insignificant value to the user and some
later machine has difficulty complying with the required
predictability. Whereas specifying initially that an operation
is unpredictable might have been quite acceptable,
relaxing the architecture definition to permit unpredictability
has certain risks, because some programs may
have come to depend on the initial, precise definition.
Thus the architect has to make a deliberate decision about
the extent of predictability.
The System/360 architecture did not provide adequate
precision and detail in some areas. Because there was no
specification of the priority in which concurrently existing
program exceptions are recognized, programming of
virtual machines was made difficult. Because the sequence
and concurrency for storage accesses were not
specified, processors could not communicate reliably
using shared main storage. And because not enough
details in machine-check handling were specified, the
possibility of model-independent recovery after an equipment
failure was reduced. The 1973 edition of the System/
370 definition was more detailed and precise, but, for the
sake of simplicity of the architectural model, specified as
predictable some aspects that, as experience indicated,
should not have been. An appendix in the 1980 edition of
the System/370 Principles of Operation [16] lists six
changes where the requirements for predictability have
been relaxed. These changes concern such aspects as
indicating an access exception for an operand when the
instruction can be completed without the use of the
operand, and they are unlikely to affect any program.
A. PADEGS IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
• Assists
In addition to the general-purpose architecture included
in the Principles of Operation, many CPUs include special-
purpose functions to improve the performance of a
specific programming system. These functions, referred
to as assists, comprise frequently occurring instruction
sequences of a particular application, and a single operation
code (or the occurrence of some other condition)
may invoke the execution of an extensive procedure.
The assists are made possible by microprogramming
and are implemented mostly (and in most machines
exclusively) in microcode. They are particularly effective
in improving performance when the function includes an
interruption sequence and the associated program action;
for example, w^hen operating under VM/370, depending
on the model and the operating system, a 40-65% reduction
in elapsed time due to the VM assist has been
measured [40].
The assists, however, are temporary internal interfaces
and are not intended for application-program development.
The functions may change between releases of the
operating system, and, since the design decisions may be
made on the basis of tradeoflFs involving only a few
specific machines, they may vary between models.
• Levels of compatibility
With the establishment of the operating system as an
essential component of a user's installation, peirt of the
architected machine interface is becoming an internal
interface between the machine and the operating system.
The dynamic-address-translation mechanism and machine-
check indications are some examples of functions
that do not directly affect the user, but the operatingsystem-
dependent nature of the interface is particularly
emphasized by the introduction of the assists. Furthermore,
since the larger models normally are used with
functionally richer operating systems and since the smaller
models are usually restricted to those with lower
storage requirements, an affinity has developed between
machine power and operating-system power. Because of
the nature of this affinity, it is not essential that the part of
the machine interface affecting only the operating system
be the same on all machines.
This evolution points out that two types of requirements
for compatibility have to be considered. In order
that old application programs run on new machines, the
machine, jointly with the system program, must ensure
that the basic facilities intended for application-program
development continue to be available. On the other hand.
IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981
changes may be acceptable in those facilities that are
available to and affect only a system program or that can
be masked by the system program from the application
program. Indeed, such changes have to be expected,
since they make it possible to improve the performance of
system functions.
Such changes (as contrasted to extensions) have been
introduced at different times into the System/360 and
System/370 architectures. In the VSE mode on the 4300
processors, the one-level-addressing facility replaced the
dynamic-address-translation facility in order to improve
virtual-storage management for small systems; it affected
only the interface between the machine and the DOS/
VSE operating system that uses it. Similarly, it was
feasible to phase in the extended-control (EC) mode, with
the associated changes in interruption control and the
PSW format, since the machine format affected only parts
of the control program. The OS/VS2 operating system,
however, continued for years to maintain the original
PSW format in areas where the format was exposed to the
user, such as in the trace information.
Architecture control
The design of a compatible line of machines required a
strict separation of the architecture and machine-design
functions and the introduction of methodology for the
control of architecture. One of the major effects of
System/360 was to establish architecture as an autonomous
function and to introduce the management tools,
discipline, and procedures for adopting and controlling
architecture [9].
Recognizing that any differences in wording may imply
differences in function, consistency is achieved by having
only one specification of the architecture; it tells IBM
machine designers the functions the machine must provide,
and it describes to IBM programmers how the
machine operates. The same specification is made available
outside IBM as the Principles of Operation [16, 18],
and is the only authoritative specification that describes
the architecture. An analogous specification exists for the
I/O interface [24].
A set of procedures have been established for the
development of an architecture, starting with the conception
of the idea and ending with the formal adoption of a
definition. These procedures provide for the assessment
of the cost and value of a function and for the approval of
the architecture by machine and software implementers.
Rules have been established about the extent of architectural
compatibility [16], and provision is made for deviating
from the common definition.
Although the implementation of a line of compatible
computers did not take an undue amount of efifort, the
design and control of architecture proved to require more
attention to detail than originally anticipated. Furthermore,
experience with Systeni/360 and its subsequent
extensions has shown that the management of architecture
must be an ongoing operation to ensure a consistent
technical interpretation and to ensure that the evolution
of the architecture structure is governed by a consistent
set of principles and a design philosophy.
Conclusion
System/360 architecture has provided the basis for a
number of machine generations, and it has been able to
evolve to respond to new technologies, programming-
system structures, and user requirements. This has been
possible because of the soundness of its basic structure,
the rigorousness of its definition, and the recognition of
the autonomy of the architecture function.
As machine, software, and system-design technologies
advance, further evolution of the architecture is inevitable.
Changes will be made to better meet user needs and
to allow more efficient design of machines and their
associated programming systems. Because of the magnitude
of the investment in System/370 architecture, however,
it will be even more essential to ensure compatibility
with the current architecture for those interfaces that
are exposed to the user and are intended for application-
program development.
Borgata Hotel Casino & Spa in Atlantic City - JetXtra
ResponderExcluirBorgata Hotel Casino 경상남도 출장안마 & Spa · Check 익산 출장안마 out what's available in store · Check out what's available 파주 출장마사지 at the Borgata Hotel Casino & 대구광역 출장마사지 Spa 제천 출장샵