Program Materialization and Observability

The program template is the only way the characteristics of a program can be observed above the MI. This template is the output of the HLL compilers and it is the lowest level at which the components of a program can be seen and manipulated above the MI. Below the MI, the program exists as an MI system object, and all MI instructions that work with this object treat it as an entity.

Inside the object is the IMPI or PowerPC instruction stream. The object is encapsulated, meaning it is not possible to look inside. While this provides technology independence, the instruction stream is not visible, so neither is the final form of the program.

There are times, however, when the application or operating system software would like to look at the characteristics of a program. Fortunately, an MI instruction allows a program to be materialized. The materialize program instruction points to an encapsulated program object and re-creates the program template for that program. Materialization is the opposite of encapsulation.

You might find it difficult to imagine how materialization can be done. After all, reverse compiling is not a very well developed technology, and researchers have tried to accomplish it for years.

So how does the AS/400 do it? It cheats. The AS/400 doesn’t reverse compile the IMPI or PowerPC instruction stream. Instead, a copy of the program template is kept with the object. When an MI instruction requests that a program be materialized, the copy of the program template is returned to the requester.

Keeping the program template with the MI system object has given both the System/38 and the AS/400 capabilities that other systems do not have. A change to the internal instruction set can be made without having an impact on customer applications. Such changes are first put into a new version of the translator, then each program is retranslated using the program templates. Finally, the new instruction stream is encapsulated back into the object. All of this takes place below the MI, with no customer involvement. A classic example, the introduction of the System/38’s Model 7, illustrates how this has worked in the past.

When the System/38 was first introduced, it was a totally new system. It had an all new instruction set, all new applications, and an all new operating system. As it turned out, no one was sure how the instructions would be used. Programmers typically refer to instruction usage patterns to optimize the hardware implementations to achieve the highest possible system performance, and high-usage instructions need to run fast.

Originally, the IMPI instruction set only had an 8-bit op-code. This meant we could have only 256 instructions (2⁸ = 256). As time went on and people began to write applications for the System/38, we discovered new functions that could benefit the applications. We continued to invent new instructions (a form of mental illness!) and pretty soon ran out of IMPI op-codes.

There is the tension between keeping the number of operations small, so as not to be unwieldy and redundant, and the desire to simplify complex tasks. It would be nice to say a scientific method is used to design instruction sets, but it isn’t. Doing so is more of an art than a science. It would have taken us a couple years to achieve what we considered an optimum IMPI instruction set. So we decided to add op-code extenders to the IMPI instruction format to accommodate these new instructions.

By this time, we also knew how the existing IMPI instructions were being used and saw ways to improve performance by remapping the more frequently used instructions into different formats that executed faster. Remapping op-code assignments meant that an instruction that was, say, a load on previous hardware looked like a branch to the new hardware. Such a change would create havoc in any “normal” systems, but not in a System/38, because it was technology independent.

When a customer upgraded to the new hardware, a new version of the translator was also installed. Each program in the system had an object header that, among other things, showed what level of translator was used to create the program. The first time a program ran, the system looked at the header and saw the program was an old version. The program template associated with the object was run against the new translator and the new IMPI code was put in the object. The program was then executed. This retranslation happened only once. Subsequent calls of the program would use the new code.

This approach worked very well, but there was one problem. A number of customers called us and said, “I just installed the new system and my main application program ran slower.” Of course, we knew why. The first time an application ran, it was retranslated, and that added time. What do you suppose we told them? Obviously, we said, “Try it again.”

This same technique of retranslating programs under-the-covers is used to move to the RISC processors. The difference now is that customers are being told that this will work only if they have not deleted observability. What has changed since the System/38 days?

The AS/400 was intended to consolidate both the System/36 and System/38 product lines. The System/38 customers were accustomed to having systems with larger memories and larger amounts of disk space. System/36 customers always got by with smaller capacities. The size of programs, in particular, disturbed many System/36 customers — the programs were way too big.

The programs in the AS/400 were big because two copies of the program were kept: the encapsulated form and the program template. To minimize the amount of disk needed, an option was given to customers. They could free up disk space by throwing away the program template. This option was called Delete Program Observability because the program could no longer be observed with a materialize instruction.

Customers and ISVs who have deleted observability of some or all of their programs have to go back to the HLL source code and recompile the source before they can move to the RISC processors. This move is still easier than it is for most other systems, but it is not as automatic as when the program template is still in place.