| Previous | Table of Contents | Next |
In Chapter 1, we saw that because levels of abstraction have been added to most computer systems, we can think about a computer having multiple levels of architecture. The two most significant levels in the AS/400 are the Technology Independent Machine Interface (MI) architecture and the PowerPC RISC architecture.
The definition of the PowerPC architecture was made with an obvious hardware bias. As with all processor architectures, the hardware chip designers, who had a set of implementations in mind, played an important role in its definition. They left out certain desired functions because those functions would have exceeded the available hardware on a particular chip. They had to redefine other requested functions to ensure that the processor cycle time for one of the designs could be maintained. There is nothing inherently wrong with this approach, because a hardware architecture that cannot be built is of little use. At the same time, a hardware-driven architecture guarantees obsolescence at some point in the future.
In fairness, some hardware-driven architectures have survived for many years. For example, Intel has successfully kept its x86 processor architecture current since the early 1980s. Starting with the Intel 8086, the organization has continued to add functionality as hardware technology has evolved to allow more transistors to be packaged on a single chip. And Intel made great strides as it delivered the 186, 286, 386, 486, Pentium, Pentium II, and Pentium Pro family of processors. To ensure software compatibility, 32-bit extensions were added to the original 16-bit architecture. The multimedia extension (MMX) instructions that were added in 1997 maintained compatibility by reusing the existing floating-point registers rather than defining new registers. To keep a competitive level of performance, Intel added a RISC microinstruction set to the Pentium Pro and Pentium II processors. Each x86 CISC instruction is implemented with a sequence of RISC instructions on the chip. This use of RISC technology continues to extend the life of the x86 architecture.
The MI architecture definition is not tied to the hardware. It is a logical, not a physical, interface to the system. As I described in Chapter 1, the MI architecture provides a complete set of APIs for OS/400 and all application programs. This set of APIs is a complete set by definition; that is, there is no way a system or an application program can go around the MI boundary. The only way to communicate with the hardware and some of the system software below the MI is through the MI boundary. This characteristic distinguishes the MI architecture from an API-centric architecture, which permits applications to go around the APIs and become dependent on the underlying hardware and software.
At the time the MI architecture was defined, the term API was not in vogue, so the designers simply called these modifications instructions. To show that the architected interface was to support both application and system software, the designers chose the name machine interface. Keep in mind that the I in API is the I in MI. The MI instructions are APIs.
How were the original designers of the MI architecture so smart they could define a complete set of APIs, to be used by OS/400 and all applications, that would last forever? The answer is, they weren’t, and they couldn’t. As new applications were added, new APIs to support those applications had to be defined in the MI. The designers made the definition of the MI architecture so expandable that new APIs could be added at any time to support new application or operating-system functions. Today, APIs are constantly being added. This means the MI architecture will never become obsolete because it changes as needs for new functions develop. Because all the older APIs remain intact, previously written applications are also protected by the MI boundary.
The MI architecture has two components: a set of instructions and the operands upon which those instructions act. Some of these operands are the traditional bit and byte operands found in conventional computer architectures. Other operands are complex data structures, called objects. An object is the only data structure that is supported as part of the MI architecture.
A computer generally represents its information resources, such as directories, database files, and physical device descriptions, as data structures or as blocks in memory with predefined fields. Application and system software directly access and manipulate the fields in these data structures. The knowledge of what that data structure represents and how it can be manipulated remains with the software.
An object at the MI boundary is a container. The container holds the data structure representing an information resource. If, instead of application and operating-system software manipulating the data structure directly with bit- and byte-level instructions, only instructions that treat the object as an entity are allowed, a level of independence can be achieved.
With the use of objects, application and system software no longer know about the precise format of a data structure. That knowledge is contained within the object itself and is not visible outside the object. Because it is not visible, any changes to the data structure have no impact on application or system software. The software is independent of the underlying structure. This characteristic of hiding the internal details is called encapsulation. We discuss encapsulation and the internal structure of an object in Chapter 5.
In this chapter, we focus primarily on the set of instructions that are part of the MI architecture. We will see that there are instructions that operate on conventional data (we will look at some examples) and instructions that operate on objects. A detailed discussion of objects and the instructions that operate on them begins in Chapter 5 and continues in subsequent chapters. We begin our discussion here by looking at how compilers use the MI to generate the code that the hardware executes. We then look at the characteristics of the MI and the MI programs. Finally, we examine in more detail the structure of the MI instructions.
| Previous | Table of Contents | Next |