| Previous | Table of Contents | Next |
In 1990, a new RISC processor architecture was being defined for future models of the AS/400. The original processor architecture, which had the unwieldy name Internal Microprogrammed Interface, or IMPI3 for short, had been defined in the mid-1970s for the original System/38. This architecture was designed to support interactive transaction-processing commercial applications. IMPI was primarily a memory-to-memory architecture. Data could be fetched from memory, modified by the processor, and put back into memory, all in one instruction. Interactive, transaction-processing applications typically move lots of data but modify very little of that data. Consider an inventory update operation.
3I gave this name to the internal interface of the System/38 in the mid-1970s, assuming that it would be changed before the system was announced. It wasn’t and has caused problems ever since. Many people like to talk about the IMPI interface. Of course, the word interface is redundant. Note that MI has the same problem. At one point someone decided the last I in IMPI should be instruction. This didn’t work either, because we talk about IMPI instructions. Finally, someone dropped the last I to solve the redundancy problem. IMP suddenly had no meaning, and conjured up pictures of a small, mischievous demon in the system. That name didn’t last long. The move to PowerPC is finally solving our naming problem.
A customer has just called in and placed an order. As a part of the application, we need to update the inventory record for each item sold. The inventory record for the item is fetched from memory or, more likely, from disk. The quantity field is checked to see whether there is a sufficient amount to satisfy the sales request and, if there is, the quantity is decremented by the amount sold. Finally, the updated record is stored back into memory where another user of the system can access it.
The operation just described can be considered a transaction by itself, or it may be a part of the larger sales transaction. In either case, it is transaction processing. It is also interactive because it is driven by the person at the terminal who received the order. Getting the response back to that person quickly is extremely important. Thus, a processor that can move lots of data and complete the operations in a short time is critical to building a successful interactive transaction-processing system. The AS/400 excels at this type of application.
Over the years, we at IBM have examined thousands of applications written for the AS/400 and other Rochester systems. These commercial applications, designed for a multiuser system, share some common characteristics. Some of the common characteristics we have found are
Contrast this type of application with a typical engineering-scientific application performed on a technical workstation. Such applications are often referred to as compute-intensive because they tend to do lots of computations on relatively small amounts of data. They typically have small instruction working sets with lots of tight loops executing floating-point arithmetic. Even their I/O is often sequential rather than random. As Cray demonstrated, a processor that works on data only in registers, as a RISC processor does, is the best choice for this type of application.
Although the commercial applications are still the mainstay, more and more compute-intensive applications have found their way into the AS/400. The move to client/server computing, in particular, has increased the need for the AS/400 to improve its compute-intensive performance. In the client/server model, the application is split between the client, which may be either a PC or a network computer (NC), and an AS/400 as the server. A server application tends to require more operations to be performed than does an interactive application. In the future, new applications also are likely to require more computing power.
The IMPI architecture was extended and modified several times since it was originally conceived. Even with those changes, it cannot be considered a high-performance computational architecture. It was obvious to most of us in Rochester that RISC processor characteristics should be added to satisfy the computational performance needs for the future. Thus, in 1990, we began an effort to add RISC features to the IMPI.
We did briefly consider using the processor from the RS/6000 but quickly dismissed the idea. The POWER architecture was originally designed for technical computing. It was lacking some of the characteristics we needed for commercial computing. In addition, it could not handle large amounts of data as efficiently as we needed.
Most RISC processors at the time were 32-bit designs. This means the width of the processor and its registers is only 32 bits. Many of these processors did have 64-bit floating-point registers, but their integer registers — those used for commercial computing — were only 32 bits. Because a RISC processor can only move data to and from its registers, the 32-bit size quickly becomes a bottleneck when lots of data needs to be moved through the processor. CISC architectures such as IMPI can perform memory-to-memory instructions, which process data without going through the registers, so they essentially bypass the bottleneck.
| Previous | Table of Contents | Next |