Initially, we decided to build the first generation processors with only the 64-bit mode. After all, the AS/400 wouldn’t use the 32-bit mode and no one else would use these early processors, so it didn’t make sense to include the full architecture. That decision was reversed about a year later when it became apparent that the AS/400 should be able to run any application software written for PowerPC processors. Because much of the PowerPC software would be written for 32-bit processors, we needed to include the 32-bit subset in all our processors. This would also allow other IBM systems to use our follow-on PowerPC processors.

The software effort to port the microcode of the AS/400 to the new processors also started in earnest at this time. Here was the opportunity to redo the internals of the AS/400 operating system, something that hadn’t been done since the original System/38 design. As long as we were going to modernize the internals, we decided to go all the way and use the latest object-oriented programming methodologies. We planned to have the most modern operating system in the industry.

Mike Tomashek was given the responsibility to put together the organization to rewrite the operating system internals. Mike knew he didn’t have the people or the skills to pull this off in the time he had. Common wisdom said it couldn’t be done. Mike worked with key developers such as Bill Berg and Chris Jones to put a plan in place. They needed to hire hundreds of new people, train them in object-oriented technologies, and rewrite the most critical part of the AS/400 operating system in a short period of time. Mike didn’t spend too much time on the plan. He just declared it would work, and went full speed ahead. There was no time to look back or debate the topic.

We started our massive hiring campaign for system programmers in late 1991. Ads began to appear in several national newspapers looking for system programmers with C++ programming experience to come to Rochester. Before we were done, we had hired several hundred new programmers. Many industry observers at the time wondered just what we were up to, and now they know.

Before we go into more detail about the PowerPC architecture, we need to bring out our chili pepper rating system. The information in the rest of the chapter is not for everyone. We include it for those who want more details. Notice that when we get into a discussion of the processor implementations, the material gets even hotter. If you decide to sample some of this information and find it too hot to handle, simply skip over these sections to something milder.

The PowerPC Architecture

In most respects, the PowerPC architecture is fairly conventional in that it contains all the characteristics usually associated with a RISC architecture. It has fixed-length instructions, register-to-register architecture, simple addressing modes, and a large set of registers. The PowerPC architecture also has features that set it apart from other architectures.

As already mentioned, the PowerPC architecture was defined as a full 64-bit architecture that has a 32-bit subset. The architecture permits 32-and 64-bit versions of PowerPC processors, but all processors are required to support, at a minimum, the 32-bit subset. The architecture defines a 32/64-bit mode switch that the operating system can set to allow a 64-bit processor to run 32-bit programs.

The entire instruction set is designed around the idea of a superscalar implementation. Recall from our earlier discussion that in a superscalar processor, multiple instructions can be dispatched to multiple pipelines during the same clock cycle. The processor hardware examines the instruction stream and dispatches as many independent instructions as it can, typically two to four per cycle. The dispatched instructions can then execute concurrently and even finish out of order. This added parallelism can greatly increase the overall processor performance.

Instructions are dispatched simultaneously to the independent execution units. Conceptually, the PowerPC structure is shown in Figure 2.3. This figure shows a branch unit, a fixed-point unit, and a floating-point unit. Also shown is the instruction cache (I-Cache),⁵ the data cache (D-Cache), the main memory, and the I/O space, which in the architecture looks like a part of the memory.

---

⁵A cache is a small fast memory that acts as a buffer for the main memory. Most RISC processors have separate caches to hold instructions and data. In a single-chip processor, the caches can either be located on the processor chip or on separate chips, while the main memory is always packaged on separate chips.

---

Figure 2.3  The PowerPC Architecture Model

The PowerPC architecture defines an independent set of registers for each of the three execution units. Each instruction defined in the architecture can execute in only one type of unit. Thus, each unit has its own set of registers plus its own instruction set. These execution units are often called processors because they have all the characteristics of processors. A PowerPC processor can be thought of as having three separate processors — the execution units. Note also that it is possible to have more than one execution pipeline in each execution unit. If floating-point performance is important for, say, a model optimized for NIC, two or more pipelines may be incorporated into the floating-point unit. In this way, more than one floating-point instruction can be executing in the unit at the same time. The same is true for the other two execution units. PowerPC processor implementations can be built that allow five or more instructions to execute concurrently.

The advantage of this design is not only that multiple instructions can be executing concurrently, but also, because of their separate resources, minimal communications and synchronization are required between units. Execution units can adjust to the changing dynamics of an instruction stream and allow one instruction to slip past another and complete out of order.