; Jump to Label if R4=0
BEQZ R4, Label
; Jump to Label if R3 != R4
BNE  R3, R4, Label

; 在指令执行阶段需要计算 R1+0
LD R4,0(R1)
; 在指令执行阶段需要计算 R1+12
SD R4,12(R1)

; 在指令执行阶段需要计算 R2+R3
DADD R1,R2,R3

; 在指令执行阶段需要计算 R2+0x10;
DADD R1, R2,0x10

LD R4, 4(R1)
SW R3, 4(R1)

; R2+R3的计算在指令执行阶段已经完成，而结果保存在ALU部件中，在回写周期运算结果被送到R1。
DADD R1, R2, R3

对于内存读取来说(LD指令)，把在内存访问周期得到的结果保存到目标寄存器中，例如：

LD R4, 4(R1)

在这个简单的流水线实现方案中，各类指令的操作周期如下：

在上面这个例子中，把一条无论转移是否发送都必须执行的指令放到延迟槽中，如果转移发生时，对该条指令的取指工作已经完成，于是继续执行这条指令，这并不影响程序原本的逻辑。虽然在这个我们的例子中，引入通过延迟槽之后，转移指令已经不会对流水线带来性能上的影响。然而在现实中却比本例复杂的多(例如Pentium4拥有20多级的流水线，又被称为超级流水线。)，因此延迟槽只能相对的减小转移指令带来的性能损失。

转移预测分为静态转移预测和动态转移预测，静态转移预测就是，当CPU遇到转移指令时，总是假设转移条件满足(或者不满足)，因此下一取指周期时总是把转移目标作为指令地址(或者总是顺序取值。)。而动态转移预测则是通过在CPU内部增加专门的硬件模块，例如：转移历史表，转移目标缓冲器等。

静态转移预测需要编译器的支持，例如GCC提供的__builtin_expect()就是用于这个目的。现在我们假设某个构架的CPU采用静态转移预测，并且总是假定转移条件不满足，因此在遇到转移指令时也顺序取指令。那么对于下面的代码编译器有两种处理方式：

 ......
if (var == 5) {
var += 5;
}
.......

编译后，代码布局可能有一些两种可能：

   ......
# 假设var变量被分配到寄存器R3中
BEQ R3, #5, Label
......
Label:
DADD R3, R3, #5;
......

或者是下面这个样子：

  ......
BNEQ R3, #5, Label
DADD R3, R3, #5;
Label:
......

对于顺序取指的静态转移预测来说，如果程序运行中转移条件(var==5)成立的次数远远大于不成立的次数，第二部分代码要优于第一部分代码，这时我们可以使用GCC提供的__builtin_expect()来通知GCC：

    ......
if (__builtin_expect( (var == 5), 1) ) {
var += 5;
}
.......

这样GCC就知道(var==5)这个条件成立的次数较多，于是按照前面第二种情况生成目标代码。

相反，如果转移条件(var==5)不成立的次数远远大于成立的次数，则一部分代码优于第二部分，此时可以使用：

  ......
if (__builtin_expect( (var == 5), 0) ) {
var += 5;
}
.......

这样就可以保证让GCC把按照前面第一种情况生成目标代码。最后，我们需要再次提醒的是：只有在目标平台的处理器和GCC同时支持的情况下，按照这种方式生成目标代码才有意义。

由于__builin_expect()看起来不太直观，于是在Linux内核中定义了likely()和unlikely():

#define likely(x)    __builtin_expect(!!(x), 1)
#define unlikely(x)  __builtin_expect(!!(x), 0)
/* 对于条件成立的次数多的，我们使用likely() */
if (likely(var==5)) {
......
}
/* 否则使用unlikely(). */
if (unlikely(var==5)) {
......
}

双向推测执行需要更多的执行部件，CPU在遇到转移指令时，在两个方向上同时取指令执行，等地转移结果出来后，抛弃错误的那个方向上的结果。