A Tour Of The Pentium Pro Processor

Microarchitecture Essay, Research Paper

A Tour of the Pentium Pro Processor Microarchitecture

Introduction

One of the Pentium Pro processor’s primary goals was to significantly exceed the

performance of the 100MHz Pentium processor while being manufactured on the same

semiconductor process. Using the same process as a volume production processor

practically assured that the Pentium Pro processor would be manufacturable, but

it meant that Intel had to focus on an improved microarchitecture for ALL of the

performance gains. This guided tour describes how multiple architectural

techniques – some proven in mainframe computers, some proposed in academia and

some we innovated ourselves – were carefully interwoven, modified, enhanced,

tuned and implemented to produce the Pentium Pro microprocessor. This unique

combination of architectural features, which Intel describes as Dynamic

Execution, enabled the first Pentium Pro processor silicon to exceed the

original performance goal.

Building from an already high platform

The Pentium processor set an impressive performance standard with its pipelined,

superscalar microarchitecture. The Pentium processor’s pipelined implementation

uses five stages to extract high throughput from the silicon – the Pentium Pro

processor moves to a decoupled, 12-stage, superpipelined implementation, trading

less work per pipestage for more stages. The Pentium Pro processor reduced its

pipestage time by 33 percent, compared with a Pentium processor, which means the

Pentium Pro processor can have a 33% higher clock speed than a Pentium processor

and still be equally easy to produce from a semiconductor manufacturing process

(i.e., transistor speed) perspective.

The Pentium processor’s superscalar microarchitecture, with its ability to

execute two instructions per clock, would be difficult to exceed without a new

approach. The new approach used by the Pentium Pro processor removes the

constraint of linear instruction sequencing between the traditional “fetch” and

“execute” phases, and opens up a wide instruction window using an instruction

pool. This approach allows the “execute” phase of the Pentium Pro processor to

have much more visibility into the program’s instruction stream so that better

scheduling may take place. It requires the instruction “fetch/decode” phase of

the Pentium Pro processor to be much more intelligent in terms of predicting

program flow. Optimized scheduling requires the fundamental “execute” phase to

be replaced by decoupled “dispatch/execute” and “retire” phases. This allows

instructions to be started in any order but always be completed in the original

program order. The Pentium Pro processor is implemented as three independent

engines coupled with an instruction pool as shown in Figure 1 below.

What is the fundamental problem to solve?

Before starting our tour on how the Pentium Pro processor achieves its high

performance it is important to note why this three- independent-engine approach

was taken. A fundamental fact of today’s microprocessor implementations must be

appreciated: most CPU cores are not fully utilized. Consider the code fragment

in Figure 2 below:

The first instruction in this example is a load of r1 that, at run time, causes

a cache miss. A traditional CPU core must wait for its bus interface unit to

read this data from main memory and return it before moving on to instruction 2.

This CPU stalls while waiting for this data and is thus being under-utilized.

While CPU speeds have increased 10-fold over the past 10 years, the speed of

main memory devices has only increased by 60 percent. This increasing memory

latency, relative to the CPU core speed, is a fundamental problem that the

Pentium Pro processor set out to solve. One approach would be to place the

burden of this problem onto the chipset but a high-performance CPU that needs

very high speed, specialized, support components is not a good solution for a

volume production system.

A brute-force approach to this problem is, of course, increasing the size of the

L2 cache to reduce the miss ratio. While effective, this is another expensive

solution, especially considering the speed requirements of today’s L2 cache SRAM

components. Instead, the Pentium Pro processor is designed from an overall

system implementation perspective which will allow higher performance systems to

be designed with cheaper memory subsystem designs.

Pentium Pro processor takes an innovative approach

To avoid this memory latency problem the Pentium Pro processor “looks-ahead”

into its instruction pool at subsequent instructions and will do useful work

rather than be stalled. In the example in Figure 2, instruction 2 is not

executable since it depends upon the result of instruction 1; however both

instructions 3 and 4 are executable. The Pentium Pro processor speculatively

executes instructions 3 and 4. We cannot commit the results of this speculative

execution to permanent machine state (i.e., the programmer-visible registers)

since we must maintain the original program order, so the results are instead

stored back in the instruction pool awaiting in-order retirement. The core

executes instructions depending upon their readiness to execute and not on their

original program order (it is a true dataflow engine). This approach has the

side effect that instructions are typically executed out-of-order.

The cache miss on instruction 1 will take many internal clocks, so the Pentium

Pro processor core continues to look ahead for other instructions that could be

speculatively executed and is typically looking 20 to 30 instructions in front

of the program counter. Within this 20- to 30- instruction window there will be,

on average, five branches that the fetch/decode unit must correctly predict if

the dispatch/execute unit is to do useful work. The sparse register set of an

Intel Architecture (IA) processor will create many false dependencies on

registers so the dispatch/execute unit will rename the IA registers to enable

additional forward progress. The retire unit owns the physical IA register set

and results are only committed to permanent machine state when it removes

completed instructions from the pool in original program order.

Dynamic Execution technology can be summarized as optimally adjusting

instruction execution by predicting program flow, analysing the program’s

dataflow graph to choose the best order to execute the instructions, then having

the ability to speculatively execute instructions in the preferred order. The

Pentium Pro processor dynamically adjusts its work, as defined by the incoming

instruction stream, to minimize overall execution time.

Overview of the stops on the tour

We have previewed how the Pentium Pro processor takes an innovative approach to

overcome a key system constraint. Now let’s take a closer look inside the

Pentium Pro processor to understand how it implements Dynamic Execution. Figure

3 below extends the basic block diagram to include the cache and memory

interfaces – these will also be stops on our tour. We shall travel down the

Pentium Pro processor pipeline to understand the role of each unit:

?The FETCH/DECODE unit: An in-order unit that takes as input the user program

instruction stream from the instruction cache, and decodes them into a series of

micro-operations (uops) that represent the dataflow of that instruction stream.

The program pre-fetch is itself speculative.

?The DISPATCH/EXECUTE unit: An out-of-order unit that accepts the dataflow

stream, schedules execution of the uops subject to data dependencies and

resource availability and temporarily stores the results of these speculative

executions.

?The RETIRE unit: An in-order unit that knows how and when to commit (”retire”)

the temporary, speculative results to permanent architectural state.

?The BUS INTERFACE unit: A partially ordered unit responsible for connecting the

three internal units to the real world. The bus interface unit communicates

directly with the L2 cache supporting up to four concurrent cache accesses. The

bus interface unit also controls a transaction bus, with MESI snooping protocol,

to system memory.

Tour stop #1: The FETCH/DECODE unit.

Figure 4 shows a more detailed view of the fetch/decode unit:

Let’s start the tour at the Instruction Cache (ICache), a nearby place for

instructions to reside so that they can be looked up quickly when the CPU needs

them. The Next_IP unit provides the ICache index, based on inputs from the