| Previous | Table of Contents | Next |
The earliest language compilers on the System/38 and the AS/400 generated the MI instructions in a fairly direct manner. Although they did go through an assembler level, there was no common intermediate form within the compiler itself. The MI instructions were the intermediate form. Examples of this type include the compilers for RPG/400 and for CL, the command language of the AS/400.
The program model for these original languages, including the form of the program below the MI, is called the Original Program Model (OPM). Later, an extension to the OPM, called the Extended Program Model (EPM), was added for languages such as C/400. Figure 4.2 shows the steps involved to create the IMPI code for both the OPM and the EPM. Note that we are including these two models to show the evolution of AS/400 compilers. Neither the OPM nor the EPM compilers are used for the V4 RISC-only systems.
)
Figure 4.2 OPM and EPM Compilers
First, let’s look at the OPM compiler shown in Figure 4.2. The language compiler takes the HLL’s OPM source statements (along with file descriptions that are not shown) as input and generates IRP (Intermediate Representation of a Program) code as the output. IRP is essentially the assembler form of the MI instructions. The next step in the process converts the IRP code to the MI instructions. The component that performs this operation is called the Program Resolution Monitor (PRM). The PRM creates a program template, called the OPM Program template in the figure, that contains the MI instruction stream and other data items. Templates are used to create MI objects. The translator below the MI uses the program template to create the program object that contains the IMPI instructions. (We examine the contents of a program template in a later section.)
The OPM example shows the classical approach of a compiler generating the assembler form of the program (the IRP) before the assembler (the PRM) generates the binary machine level (the program template). The translator operation is an extra step in the process. Compiles on an AS/400 require extra steps, which also explains why they can take longer to run than compiles on some other systems do. Note that the system user is not aware of all the steps. Initiating a compile on the AS/400 causes all these steps to look like a single operation.
As new languages, such as C/400 and Pascal, were implemented on the AS/400, some extensions had to be added to the OPM to accommodate the new EPM language compilers. The compiler steps for the EPM are also shown in Figure 4.2. The compilers for these languages are implemented with separate front and back ends. The common intermediate form inside these compilers is called U-code. A new compiler back end, called the Common Use Back End 1 (CUBE-1), was created for the AS/400.
The OPM, based on the System/38 model and designed for RPG and Cobol, had only limited support for block-structured languages such as C and Pascal. Block-structured languages are designed to enable a modular style of programming. Instead of requiring that a program be written as a single unit, these languages allow a program to be written as a series of smaller program blocks that are linked together by call instructions. The EPM enabled the implementation of these languages, but because the EPM was built without changes to the MI to support lots of calls, there was still a performance penalty when users started or called an EPM program.
The only type of call instruction originally supported at the MI was a call external. This type of call instruction is dynamic, meaning it resolves all references by name at execution time. This approach is known as late binding. Although such external calls are the most flexible, they diminish performance. In addition, the OPM supported only a single language source per program object, so external calls were used between program objects when part of a program was written in a different language.
To improve the performance of modular programming and to encourage this programming style for all languages, an architectural enhancement to the MI and to the objects below the MI was created. Introduced in 1993, this enhancement is called the Integrated Language Environment (ILE). ILE includes new language compilers, a new optimizing translator (OX), and a new binder facility to create packaged programs.1 ILE changes the way programs are created. Unlike the OPM, the output of the ILE translator is not a program object; instead, it is a new object called a module. The ILE binder packages these modules into programs.
1The optimizing translator, which is affectionately known as OX, was a joint effort between Rochester and IBM’s Haifa Research Laboratory. Haifa has expertise in machine-specific compilation techniques for pipelined, superscalar processors; Haifa developed several of the components in OX.
In addition to supporting the OPM late-bound calls, ILE introduced the ability to bind at compile time. The benefit of binding at compile time, known as early binding, is to reduce the overhead associated with the external dynamic calls. These bound, or static, calls are faster.
Before we look at this further, a few terms need a little more definition:
| Previous | Table of Contents | Next |
){kind=link}