IBM System/370 - Architecture Details

Architecture Details

S/370 also refers to a computer system architecture specification, and is a direct and mostly backward compatible evolution of the System/360 architecture from which it retains most aspects. This specification does not make any assumptions on the implementation itself, but rather describes the interfaces and the expected behavior of an implementation. The architecture describes mandatory interfaces that must be available on all implementations and optional interfaces which may or may not be implemented.

Some of the aspects of this architecture are:

• Big endian byte ordering
• One or more processors with
  • 16 32-bit General purpose registers
  • 16 32-bit Control registers
  • A 64-bit Program status word (PSW) which describes (among other things)
    • Interrupt masks
    • Privilege states
    • A condition code
    • A 24-bit instruction address
  • Timing facilities (Time of day clock, interval timer, CPU timer and clock comparator)
  • An interruption mechanism, maskable and unmaskable interruption classes and subclasses
  • An instruction set. Each instruction is wholly described and also defines the conditions under which an exception is recognized in the form of program interruption.
• A memory (called storage) subsystem with
  • 8 bits per byte
  • A special processor communication area starting at address 0
  • Key controlled protection
  • 24-bit addressing
• Manual control operations that provide
  • A bootstrap process (a process called Initial Program Load or IPL)
  • Operator-initiated interrupts
  • Resetting the system
  • Basic debugging facilities
  • Manual display and modifications of the system's state (memory and processor)
• An Input/Output mechanism - which doesn't describe the devices themselves

Some of the optional features are:

• A Dynamic Address Translation mechanism that can be used to implement a virtual memory system
• Floating point instructions

Due to the extensible nature of the interface specification, new interface could be devised without breaking the initial interface contract. Such examples are:

• ECPS:VM, a feature to assist the VM/370 operating system
• ECPS:VSE, a feature to assist the DOS operating system

Great care was taken in order to ensure that further modifications to the architecture would remain compatible, at least as far as non-privileged programs were concerned. This philosophy predates the definition of the S/370 architecture and started with the S/360 architecture. If certain rules are adhered to, a program written for this architecture will run with the intended results on the successors of this architecture.

One of the key aspect that allows this compatibility is to define that unused fields are to be set to a predetermined value (usually 0) - and that using another value leads to an exception condition being recognized. When the interface is modified, this unused field can then be used to alter the interface contract. A well formed program can then still produce the expected result even when executing on an implementation of the new interface.

Such an example is that the S/370 architecture specifies that the 64 bit PSW register bit number 32 has to be set to 0 and that doing otherwise leads to an exception. Subsequently when the S/370 XA architecture was defined, it was stated that this bit would indicate whether the program was a program expecting a 24 bit address architecture or 31 bit address architecture. Thus, most programs running on the 24 bit architecture can still run on 31 bit systems and the new 64 bit system.

However, not all of the interfaces can remain compatible. Emphasis was put on having non control programs (called problem state programs) remain compatible. Thus, operating systems have to be ported to the new architecture because the control interfaces can (and were) redefined in an incompatible way. For example, the I/O interface was redesigned in S/370 XA making S/370 program issuing I/O operations unusable as-is.