Inside a Program Template

In this section we explore the internals of a program template. For our study, we will use the OPM program template, even though the RISC-based systems do not supported it. I’ve chosen the OPM for two reasons. First, we can illustrate some of the more interesting concepts behind the original design of the MI instruction set. Second, some of the details of the ILE program template have never been made public. Let’s look at some of the additions that were made for the ILE program model before we get into the OPM program template.

With the ILE program model compilers, new instructions were added to the MI. Some of these new instructions support a structure that is closer to the W-code the ILE compilers use, but they are not exactly the same as the W-code instructions. The IBM laboratory in Toronto, Ontario, Canada, owns the W-code. The Toronto Laboratory has been unwilling to license the W-code interface to anyone outside of IBM. If they did, others could develop and sell compilers for systems such as the AS/400. We decided to define MI instructions that were similar to, but not exactly the same as, W-code so we would not have to involve Toronto if the decision was ever made to open this interface to other compiler vendors.

A better target for the ILE compilers is a stack machine, so the MI was extended to support stacks. A stack consists of data items stored in consecutive order. The first item pushed onto the stack is said to be at the bottom of the stack. The item most recently pushed onto the stack is said to be on the top of the stack. Instructions with no operands are used in conjunction with a stack. The operands for an instruction are found by popping the top two operands from the stack. By contrast, the OPM instructions have the two operands identified in the instruction itself. The ordering for instructions and data for a stack machine has the operator following the operands. This form is called postfix or reverse Polish, after the mathematician who investigated the properties of this notation.³

---

³The Polish mathematician was J. Lukasiewicz. This notation should be called Lukasiewicz notation in his honor. Unfortunately, few Americans could pronounce or spell his name, so it has been called Polish notation instead.

---

Interestingly enough, the architecture designed in 1972 had this same stack support. At the time, many of us believed that block-structured languages, such as PL/I, would become very popular in commercial computing. But RPG and Cobol were never displaced, and the stack was eliminated. Now languages such as C have brought back the stack.

A program template contains several pieces of information. The OPM program template has header information, the MI instruction stream, user data, and a structure called the object definition table (ODT). Figure 4.7 shows the instruction stream and the ODT. The instruction stream in the figure contains a sample MI instruction. The Add Numeric shown is a classic, three-operand OPM instruction. It has an op-code followed by three values in the instruction that are used to locate the three operands. Each of these values is used as an index into the ODT. The specific instruction shown requests that operand 6 be added to operand 2 and the sum be put into operand 3.

Figure 4.7  Instructions and the ODT

The ODT has two components. The first is the ODT Direction Vector (ODV). The ODV contains one entry for each operand in a program. Each entry is fixed in length so the value in the instruction stream can be used as an index into the ODV. The entries in the ODV describe the operands. In our example, operand 6 is a binary number that is 2 bytes long. Operand 3 is another 2-byte binary number, and operand 2 is a constant. Constants and other types of operands can be variable in length, and that is the reason for the second ODT component. The ODT Entry String (OES) has the variable length operands that won’t fit in the ODV. The contents of the ODV field point to the beginning of the string in the OES. In our example, operand 2 is a constant with a value of 1253.

The example shows several characteristics of the OPM MI instructions. First, our example is an Add Numeric instruction. It is not an add binary, or an add decimal, or an add floating-point; it is a generic add instruction. The ODT defines the format of the operands to be used. The example shows binary numbers, but they could have been any numeric format. The translator is responsible for generating the data conversions that are required to perform the operation.

A second characteristic shown in the example is that the OPM MI is not an executable interface. Notice that neither operand 3 nor operand 6 have associated values. The ODV entry is equivalent to a variable declaration. There is no memory to hold the variable, so the translator has to complete the compile and assign the variables to registers or memory locations.

Finally, note that the example is a fairly conventional computation instruction. An instruction that operates on an object would have a similar format, but the ODT would indicate how to find the object. We cover the specifics of object addressing in Chapter 5.

The MI Instruction Formats

Figure 4.8 shows the format of an OPM MI instruction in the instruction stream. An instruction has an op-code, an optional op-code extender, and zero or more operands. The MI was designed to be expandable, so the instruction format had to allow for growth in the number of instructions and operands. The op-code is a 16-bit field, as is the op-code extender. Each operand field, which is used to index into the ODV, was originally 16 bits long in the System/38, but the field was later expanded to 24 bits. This means that a program can have up to 16 million (2²⁴)different operands, and even that number can be extended.

Figure 4.8  MI Instruction Format

Memory conservation was not a high priority for the program template. The Add Numeric instruction, for example, would take 2 bytes for the op-code, 2 bytes for the op-code extender, and 9 bytes for the operands. That’s 13 bytes, and we haven’t even included the space for operands in the ODT. It’s not surprising that System/36 customers were upset with the amount of disk space programs used.