MIPS_primery_zadach / dandamudi05gtr guide risc processors programmers engineers

•Branch Prediction: If we can predict whether the branch will be taken, we can load the pipeline with the right sequence of instructions. Even if we predict correctly all the time, it would only convert a conditional branch into an unconditional branch. We still have the problems associated with unconditional branches. We described three types of branch prediction strategies in Chapter 2 (see page 28).

Inasmuch as we covered branch prediction in Chapter 2, we discuss the first two techniques next.

Predication to Eliminate Branches In the Itanium, branch elimination is achieved by a technique known as predication. The trick is to make execution of each instruction conditional. Thus, unlike the instructions we have seen so far, an instruction is not automatically executed when the control is transferred to it. Instead, it will be executed only if a condition is true. This requires us to associate a predicate with each instruction. If the associated predicate is true, the instruction is executed; otherwise, it is treated as a nop instruction. The Itanium architecture supports full predication to minimize branches. Most of the Itanium’s instructions can be predicated.

To see how predication eliminates branches, let us look at the following example.

The code on the left-hand side, expressed in C, is a simple if-then-else statement. The IA32 assembly language equivalent is shown on the right. The cmp instruction compares the contents of the r1 and r2 registers and sets the condition code bits (in the IA-32, these are called the flag bits). If r1 = r2, the jump equal (je) instruction transfers control to the then_part. Otherwise, the sub instruction is executed (i.e., the else_part). Then the unconditional jump (jmp) instruction transfers control to end_if. As you can see from this code, it introduces two branches: unconditional (jmp) and conditional (je).

Using the Itanium’s predication, we can express the same as

cmp.eq p1,p2 = r1,r2 (p1) add r3 = r3,r1

(p2) sub r3 = r3,r1

The compare instruction sets two predicates after comparing the contents of r1 and r2 for equality. The result of this comparison is placed in p1 and its complement in p2. Thus, if the contents of r1 and r2 are equal, p1 is set to 1 (true) and p2 to 0 (false). Because the add instruction is predicated on p1, it is executed only if p1 is true. It should be

Because there is a two-cycle latency to the first-level data cache, the add instruction is scheduled two cycles after scheduling the ld8 instruction. A straightforward optimization involves moving the ld8 instruction to cycle 1 as there are no data dependencies to prevent this reordering. By advancing the load instruction, we can schedule the add in cycle 3 as shown below:

However, when there is ambiguous data dependency, as in the following example, instruction reordering may not be possible:

In this code, ambiguous dependency exists between the first st8 and ld8 because r9 and r5 could be pointing to overlapped memory locations. Remember that each of these instructions accesses eight contiguous memory locations. This ambiguous dependency will not allow us to move the load instruction to cycle 1 as in the previous example.

The Itanium provides architectural support to move such load instructions. This is facilitated by advance load (ld.a) and check load (ld.c). The basic idea is that we initiate the load early and when it is time to actually execute the load, we will make a check to see if there is a dependency that invalidates our advance load data. If so, we reload; otherwise, we successfully advance the load instruction even when there is ambiguous dependency. The previous example with advance and check loads is shown below:

4:ld8.c r4=[r5]

We inserted an advance load (line 1) at cycle 0 or earlier so that r4 would have the value ready for the add instruction on line 5 in cycle 2. However, we have to check to see if we can use this value. This check is done by the check load instruction ld8.c on line 4. If there is no dependency between the store on line 3 and load on line 4, we can safely use the prefetched value. This is the case if the pointers in r9 and r5 are different. On the other hand, if the load instruction is reading the value written by the store instruction, we have to reload the value. The check load instruction on line 4 automatically reloads the value in the case of a conflict.

In the last example, we advanced just the load instruction. However, we can improve performance further if we can also advance all (or some of) the statements that depend on the value read by the load instruction. In our example, it would be nice if we could advance the add instruction on line 5. This causes a problem if there is a dependency between the store and load instructions (on lines 3 and 4). In this case, we not only have to reexecute the load but also the add instruction. The advance check (chk.a) instruction provides the necessary support for such reexecution as shown in the following example.

When the advanced load fails, the check instruction transfers control to recover to reload and reexecute all the instructions that used the value provided by the advanced load.

How does the Itanium maintain the dependency information for use by the check instructions? It keeps a hardware structure called the Advanced Load Address Table (ALAT), indexed by the physical register number. When an advanced load (ld.a) instruction is executed, it records the load address. When a check is executed (either ld.c

or chk.a), it checks ALAT for the address. The check instruction must specify the same register that the advanced load instruction used. If the address is present in ALAT, execution continues. Otherwise, a reload (in the case of ld.c) or recovery code (in the case of chk.a) is executed. An entry in ALAT can be removed, for example, by a subsequent store that overlaps the load address. To determine this overlap, the size of the load in bytes is also maintained.

Control Speculation

When we want to reduce latencies of long latency instructions such as load, we advance them earlier into the code. When there is a branch instruction, it blocks such a move because we do not know whether the branch will be taken until we execute the branch instruction. Let us look at the following code fragment.

// other instructions

In the above code, we cannot advance the load instruction due to the branch instruction. Execution of the then branch takes four clock cycles. Note that the code implies that the integer compare instruction that sets the predicate register p1 and the branch instruction that tests it are executed in the same cycle. This is the only exception; in general, there should be a stop inserted between an instruction that is setting a predicate register and the subsequent instruction testing the same predicate.

Now the question is: how do we advance the load instruction past the branch instruction? We speculate in a manner similar to the way we handled data dependency. There is one additional problem: because the execution may not take the branch, if the speculative execution causes exceptions, they should not be raised. Instead, exceptions should be deferred until we know that the instruction will indeed be executed. The Not-a-Thing bit is used for this purpose. If a speculative execution causes an exception, the NaT bit associated with that register is set. When a check is made at the point of actual instruction execution, if the deferred exception is not present, speculative execution was successful. Otherwise, the speculative execution should be redone. Let us rewrite the previous code with a speculative load.

skip:

// other instructions

recovery:

The load instruction is moved by at least two cycles so that the value is available in r1 by the time it is needed by the add instruction. Because this is a speculative load, we use the ld8.s instruction. And, in place of the original load instruction, we insert a speculative check (chk.s) instruction with the same register r1. As in the data dependency example, if the speculative load is not successful (i.e., the NaT bit of r1 is set), the instruction has to be reexecuted. In this case, the check instruction branches to the recovery code.

Branch Prediction Hints

Most processors use branch prediction to handle the branch problem. We have discussed three branch prediction strategies—fixed, static, and dynamic—in Chapter 2. Branch prediction strategies can accept hints from the compiler. In the Itanium, branch hints can be explicitly provided in branch instructions. The bwh completer can take one of the following four values.

spnt Static branch not taken sptk Static branch taken

dpnt Dynamic branch not taken dpnt Dynamic branch taken

The SPARC processor also allows providing hints in its branch instructions (see Chapter 5 for details).

Summary

We have given a detailed overview of the Itanium architecture. The Itanium is a more advanced processor in terms of the features provided. Compared to the other processors we have discussed so far, it supports explicit parallelism by providing ample resources such as registers and functional units. In addition, the Itanium architecture supports sophisticated speculative loads and predication. It also uses traditional branch prediction strategies. The Itanium, even though it follows the RISC principles mentioned in Chapter 3, is not a “simple” architecture. Some of its instructions truly belong to the CISC category.

Web Resources

Certainly, we have left out several elements. If you are interested in learning more about this architecture, visit the Intel Web site for recent information. The Itanium architec-

ture details and manuals are available from www.intel.com/design/Itanium/ manuals/. The architecture is described in three volumes [10, 11, 12].

Figure 8.1 ARM register set consists of 31 general-purpose register and six status registers. All registers are 32 bits wide.

In 1999, the ARMv5TE architecture introduced several improvements to the Thumb architecture. In addition, several DSP instructions have been added to the ARM ISA. In 2000, the ARMv5TEJ architecture added the Jazelle extension to support Java acceleration technology for small memory footprint designs. In 2001, the ARMv6 architecture was introduced. This version provides support for multimedia instructions to execute in Single Instruction Multiple Data (SIMD) mode.

Like the MIPS, the ARM is dominant in the 32-bit embedded RISC microprocessor market. ARM is used in several portable and handheld devices including Dell’s AXIM X5, Palm Tungsten T, RIM’s Blackberry, HP iPaq, Nintendo’s Gameboy Advance, and so on [4]. The ARM Web site claims that, by 2002, they shipped over 1 billion of its microprocessor cores [3].

In the remainder of this chapter we look at the ARM architecture in detail. After reading this chapter, you will notice that this architecture is somewhat different from the other processors we have seen so far. It shares some features with the Itanium architecture discussed in the last chapter. However, you should note that the ARM architecture development started in 1985.