previous | contents | next

One of the primary characteristics of the IBM System/38 that identifies it as an advanced computer system is its high-level machine instruction interface, which incorporates new architectural structures and provides a much higher level of function than traditional machine architectures, such as the IBM System/3. The function and architectural structures are more similar to those of high-level languages than to conventional machines. The purpose of this article is to describe the advantages and salient architectural features provided by the System/38 instruction interface, and how they are realized in the specifics of the System/38 machine.

Relevant system objectives

Many factors influence the choice of the architectural characteristics [Henry, 1978] of a new system. In System/38 the primary influences, such as anticipated user requirements and hardware technology trends, led to the adoption of some major objectives for the total system. Briefly, these were:

• Programming independence from machine implementation and configuration details
• High levels of integrity and authorization capability with minimal overhead
• Efficient support in the machine for commonly used operations in control programming, compilers, and utilities
• Efficient support in the machine for key system functional objectives, such as data base and dynamic multiprogramming.

The following sections highlight the major System/38 instruction interface concepts and features that address these objectives.

Independence from Machine Implementation and Configuration

In previous systems, the ability for users to take advantage of new technology and implement new function was limited by dependence on a specific low-level instruction interface; for example, dependence upon the hardware-implemented address size. One of the major goals of System/38 architecture was to enable users to be as independent as possible of hardware and device characteristics.

In System/38, hardware dependencies have been absorbed by internal microcode functions that provide an instruction interface, which is largely independent of hardware details. Users of the instruction interface, therefore, need not be concerned with hardware addressing [Berstis, Trutal, and Ranweiler, 1978], auxiliary storage allocation and addressing [French, Collins, and Loen, 1978], internal data structures and relationships [Pinnow, Ranweiler, and Miller, 1978], channel and I/O interface details, and internal microprogramming details (Hoffman and Soltis, 1978].

This hardware independence characteristic of the Systeml38 instruction interface is due in large measure to the use of an object-oriented interface [Pinnow, Ranweiler, and Miller, 1978] instead of the more conventional byte-oriented interface. An object is a System/38 instruction interface construct that contains a specific type of information and can be used only in a specific manner, A number of different types of objects are defined in the interface, and various object-specific instructions are provided to operate upon each object type. An example of a System/38 instruction interface object is a data space (file), which has associated instructions for operations such as the adding and deleting of records [Watson and Aberle, 1978].

Each object is created by a System/38 interface instruction that uses a user-specified data structure to define the object's characteristics and initial values. Once the object is created, its internal stored format is not apparent to the user (with the one exception discussed below). The status and values of the object may be retrieved or changed by using interface instructions, but the internal format of the object cannot be directly viewed or modified. That is, objects can be operated upon functionally, but not as a byte string. This approach prevents dependence on the internal format of the object and enables applications to remain independent of evolving internal implementations of the machine.

There is one specific exception to this shielding of the internal format of an object. A space object is a construct that can be used by a program for storage of and operation upon byte-oriented operands such as character strings and numeric values.

In addition to this object orientation, main storage and auxiliary storage addresses are not directly apparent in the System/38 instruction interface [Berstis, Truxal, and Ranweiler, 1978; Pinnow, Ranweiler, and Miller, 1978]. All interface addressing of objects is accomplished by resolving symbolic names (supplied by the user) to a pointer. A pointer is an object that is used only for addressing and does not permit examination or manipulation of the implied physical address. A system pointer gives a user the

1IBM System/38: Technical Developments, pp. 47-50. © 1978 by International Business Machines Corporation. Reprinted by permission.

533

previous | contents | next