计算机体系结构这门课里，体系结构基础和流水线原理是最容易让人产生"我懂了"错觉的两块内容。课本上的五级流水线画得干净利落，每级一个方框，箭头一画，好像就完事了；等到自己动手写模拟器、或者做那套流传很广的习题集时，才发现数据冒险、load-use 停顿、分支预测失败这些细节全在暗处等着你。这篇东西不讲教科书式的大纲，只讲我这些年反复啃这块内容时，真正帮我打通任督二脉的几个关键点：ISA 和微架构到底怎么分家、流水线的加速比是怎么被寄存器开销吃掉的、三类冒险各自能用什么手段对付、以及一个几十行的 Python 模拟器怎么写出来验证自己的想法。

适合三类人看：正在上计算机组成或体系结构课、需要把概念串起来的在校生；准备考研或面试、被"五级流水的 CPI 是多少"这类问题反复折磨的朋友；以及想动手写个简易模拟器、把理论落成代码的实践派。全文会给出可直接抄走的代码、参数计算过程和我踩过的坑，尽量做到看完就能自己复现一遍。

1. 先把"体系结构"这个词拆开看

1.1 体系结构、组成原理、数字逻辑的分界线

很多人学完一学期，仍然分不清"体系结构"和"组成原理"的区别，做题时把两者混着用。我自己的分法是：体系结构是软硬件之间那份合同，组成原理是这份合同的具体施工方案，数字逻辑是盖房子用的砖。合同一旦签了，程序员看到的东西就固定下来——有哪些指令、多少个通用寄存器、寻址方式有几种、异常怎么处理、内存模型是强序还是弱序。这些都是 ISA（Instruction Set Architecture）层面的东西。

而微架构（Microarchitecture）是另一回事。同一份 x86 的机器码，在 Intel 的芯片和 AMD 的芯片上都能跑，因为它们的 ISA 是兼容的；但里面的流水线级数、分支预测器结构、Cache 容量、乱序执行窗口大小完全不同，性能能差出一大截。这就是为什么同一份 ISA 可以对应几十种实现，而每一种实现的性能、功耗、面积都不一样。

我一开始学的时候总想着"把指令集背下来就完了"，后来才明白，体系结构真正的价值在于它决定了什么能做、什么做起来代价大。比如 RISC 选择定长指令、load/store 架构，本质上就是为了让流水线好做——这个因果关系，是理解后面所有内容的前提。

1.2 为什么必须先打牢基础再看流水线

流水线不是凭空冒出来的优化，它是对 ISA 设计的一种"回应"。你如果不清楚指令格式长什么样、操作数从哪来、结果写到哪去，看流水线冒险的时候就会一头雾水，只能死记"相邻两条指令有依赖就停一拍"这种结论，稍微变形一下就做不出来。

举个最典型的例子：为什么 RISC 普遍采用定长 32 位指令？因为定长意味着取指阶段可以在一个周期内完成，PC 加 4 就是下一条指令的地址，不需要先译码才知道指令有多长。如果指令是变长的（像 x86 那样从 1 字节到 15 字节都可能），取指和译码就必须串在一起，流水线的前两级会变得极其别扭，需要预译码缓存、指令队列等一大堆补丁。

反过来看 CISC，它在 ISA 层面提高了代码密度，省了存储空间，代价就是把复杂度全压到了硬件实现上。现在主流的做法其实是折中——对外保持 CISC 的 ISA，对内把指令翻译成类似 RISC 的微操作再送进流水线。理解了这层，你就知道 RISC 和 CISC 之争其实早就不是非黑即白的问题了。

2. 体系结构基础：五组必须嚼透的概念

2.1 冯·诺依曼循环和指令执行的五个动作

存储程序思想说起来一句话：指令和数据放同一个存储器里，CPU 按 PC 一个字一个字地取出来执行。听起来平淡无奇，但它带来的后果是深远的——取指令和取数据要抢同一个存储器端口，这就是后面"结构冒险"的根源。冯·诺依曼结构的这个瓶颈，直接催生了指令 Cache 和数据 Cache 分离的哈佛式改造。

一条指令在经典模型里要走完五个动作：取指（IF）、译码（ID）、执行（EX）、访存（MEM）、写回（WB）。把这条链路拆成一串状态机，PC 指向当前指令，IR 保存正在译码的指令，MAR 和 MDR 负责跟存储器打交道。整个循环周而复始，没有任何"智能"，就是单纯的取值、计算、存值。

关键洞察在于：这五个动作使用的硬件资源几乎是互不重叠的。取指用存储器取指令和加法器（更新 PC），译码用译码器和寄存器堆读取端口，执行用 ALU，访存用数据存储器，写回用寄存器堆写端口。资源不冲突，就具备了并行重叠的条件——这正是流水线的物理基础。如果你能自己把"哪一步用了哪些部件"画出来，流水线的可行性就不言自明了。

2.2 指令集架构：CISC 和 RISC 的取舍

把两类 ISA 摆在一起对比，很多模糊的地方会立刻清晰：

这张表里最重要的一行是"操作数位置"。RISC 规定只有 load 和 store 能碰内存，其他所有运算都在寄存器之间完成，这条规则把指令的执行阶段做得极其规整：ALU 的两个输入永远来自寄存器堆或立即数，结果永远写回寄存器堆。规则性带来的是可预测性，可预测性带来的是硬件可以做得又快又简单。

CISC 允许add [ebx+esi*4+8], eax这种一条指令里既算地址又读内存还写内存的操作，功能是强，但流水线要在一个阶段里做地址计算、段检查、内存读、加法、内存写，这一串动作没法均分到多个流水级，只能拆成微操作。我个人的经验是：做题时遇到"这条指令流水线怎么走"，先看它是不是 load/store 架构，如果题目里出现内存参与运算，多半是在考 CISC 的拆分处理。

2.3 存储层次与局部性原理

存储层次背后的两条大腿是时间局部性和空间局部性。刚访问过的数据很可能马上还会被访问（时间），刚访问过的地址附近的地址很可能被访问（空间）。循环里的数组遍历同时满足这两条，所以 Cache 对它特别友好；而随机访问一个大哈希表，两条都沾不上边，性能就全靠内存带宽撑着。

典型的层次结构和量级大致是这样的：

评价这个体系的核心指标是 AMAT（Average Memory Access Time）：

AMAT = 命中时间 + 缺失率 × 缺失代价

举个例子，L1 命中时间 4 个周期，本地缺失率 8%，缺失时要到 L2 拿，L2 命中时间 12 个周期，那么 AMAT = 4 + 0.08 × 12 = 4.96 个周期。如果把这个缺失率压到 2%，AMAT 变成 4.24，看着只省了 0.72 个周期，但乘以几十亿条访存指令，就是实打实的时间。这也是为什么 Cache 优化永远是体系结构里的重头戏——缺失率每下降一个百分点，整机性能都会有肉眼可见的变化。

2.4 性能度量：CPI、MIPS 和 Amdahl 定律

这套公式必须刻在脑子里：

CPU 时间 = 指令数 × CPI × 时钟周期 = 指令数 × CPI ÷ 主频

三个因子各自对应不同的优化方向：指令数靠编译器优化和 ISA 设计来减，CPI 靠流水线和乱序执行来降，主频靠工艺和流水线深度来提。麻烦的地方在于三者互相牵制——加深流水线能提主频，但 CPI 会因为冒险变多而恶化；减少指令数可能需要更复杂的指令，反而拉高 CPI。永远不要单独看一个指标，性能是乘法关系，木桶效应极其明显。

MIPS 这个指标我建议只当参考，别当信仰：

MIPS = 主频 ÷ (CPI × 10^6)

它天然偏爱那些指令干得少但每条都很重的机器，跑浮点密集的程序时，MIPS 高不代表实际快。真正靠谱的是跑标准测试集的实测时间。

至于 Amdahl 定律，它给所有优化泼了一盆冷水：

加速比 = 1 ÷ ((1 - p) + p ÷ s)

p 是可优化部分占比，s 是这部分的加速倍数。假设某程序 40% 的时间在做浮点运算，你把浮点单元加速 10 倍，整体加速比 = 1 ÷ (0.6 + 0.4 ÷ 10) = 1.56。也就是说，花了 10 倍的硬件代价，只换来 56% 的性能提升。这个公式最实用的地方是在动手优化之前先算一遍，判断值不值得投人力。我自己做性能调优的时候，第一步永远是先 profile 出各部分的耗时占比，占比低于 10% 的模块，再怎么优化也不碰。

3. 流水线原理：从理论加速比到真实收益

3.1 流水线为什么能加速，加速比怎么算

流水线最好用的类比是洗车。单工位洗车，一辆车从冲水、打泡沫、擦干到打蜡，四道工序全由一个工人做完，一辆车花 40 分钟。改成四个人各守一道工序，第一辆车还是要 40 分钟才能出来，但之后每 10 分钟就出一辆。吞吐量翻了 4 倍，单辆车的延迟一点没变。

把它抽象成公式。k 级流水线，每级耗时 T，处理 n 条指令：

• 不用流水线：时间 = n × k × T
• 用流水线：时间 = (k + n - 1) × T
• 加速比 S = nk ÷ (k + n - 1)

n 足够大时，S 趋近于 k，这就是"理想加速比等于流水级数"的由来。拿 n = 1000、k = 5 代进去，S = 5000 ÷ 1004 ≈ 4.98，非常接近 5。但如果 n 只有 10，S = 50 ÷ 14 ≈ 3.57，填充和排空的开销占了很大比例。

注意：这个公式默认每级耗时完全相同、没有冒险、没有额外开销。现实中这三个假设一个都不成立，所以实际加速比通常只有理论值的 60% 到 80%。做题时如果题目没说"理想流水线"，就要留个心眼，看看要不要考虑停顿。

3.2 经典五级流水线的阶段划分

五级流水线是教学和考试的主力模型，每一级的职责和用到的主要部件我整理成下面这张表，方便对照记忆：

把这条链路串起来的关键是流水线寄存器：IF/ID、ID/EX、EX/MEM、MEM/WB 四个寄存器组，每一级算完的东西必须锁存进下一级寄存器，下一周期才能被后一级使用。这些寄存器不是免费的，它们的建立时间、保持时间、传输延迟都实实在在占着时钟周期，这一点在 3.3 节展开。

阶段划分还有个隐含前提：每一级的延迟要尽量均衡。流水线的时钟周期由最慢的一级决定，如果 EX 要 500ps 而其他级只要 200ps，那整个流水线就跑在 500ps 的节拍上，其余四级有 300ps 在空转。所以真实的处理器设计里，工程师会反复调整各级的边界，把长延迟的组合逻辑拆开或者挪一部分到相邻级，这个"平衡"的过程往往比想象中耗时得多。

3.3 流水线寄存器带来的隐性成本

理论上 k 级流水线能带来 k 倍加速，但每插入一级就多一组寄存器，时钟周期不再是 T，而是 T + Tr（Tr 是寄存器的建立时间和传输延迟之和）。修正后的周期是：

T_pipe = T ÷ k + Tr

加速比变成：

S = T ÷ (T ÷ k + Tr) = 1 ÷ (1 ÷ k + Tr ÷ T)

假设某组合逻辑总延迟 T = 1000ps，寄存器开销 Tr = 50ps。理想情况下 k = 5，加速比是 1 ÷ (0.2 + 0.05) = 4，而不是 5。如果把流水线加深到 k = 10，周期变成 100 + 50 = 150ps，加速比 = 1 ÷ (0.1 + 0.05) ≈ 6.67。你会发现收益在快速递减——流水线越深，寄存器开销占比越大，而且冒险带来的停顿也越多。

这就是为什么 Pentium 4 的 31 级流水线最终被放弃，而现代高性能核心大多停留在 14 到 20 级左右。深流水线在分支预测失败时的惩罚太大了，一旦预测错了，要冲刷掉十几个周期的成果，而现代程序里的分支密集度又很高。流水线深度是个权衡，不是越深越好，做题时遇到"加深流水线到 k 级后性能如何变化"，一定要把寄存器开销算进去，不然答案会偏。

4. 流水线冒险：三类冲突的处理套路

4.1 结构冒险：硬件资源不够用

结构冒险的本质是同一个周期里，两条指令想用同一个硬件部件。最经典的场景是冯·诺依曼结构下，IF 阶段要取指令，MEM 阶段要读数据，两者都想访问同一个存储器，于是冲突。

解决办法有三个层次。最粗暴的是插入气泡，让后一条指令等一拍，代价是 CPI 上升；稍好一点的是把存储器做成双端口，一个周期能读两次，但双端口 SRAM 面积大、功耗高；最常用的是把指令 Cache 和数据 Cache 拆开，也就是哈佛结构，物理上就是两块独立的小 SRAM，各走各的，冲突自然消失。

提示：考试里如果题目说"采用统一的存储器"并且没提分离 Cache，那么 IF 和 MEM 的冲突是必须考虑的，通常需要停一拍或者用双端口。这一步漏掉，后面所有的 CPI 计算都会错。

另一个容易被忽略的结构冒险来自寄存器堆。如果一条指令在 WB 阶段要写寄存器，同时另一条在 ID 阶段要读同一个寄存器，单端口寄存器堆就会打架。工程上的做法是给寄存器堆做两个读口加一个写口，并且约定前半周期写、后半周期读。这样一来，同周期内的"读后写"冲突就被巧妙化解了，不需要额外停顿。这个"写在前、读在后"的约定在后面算数据冒险的停顿周期时会直接用到。

4.2 数据冒险：前递通路怎么救场

数据冒险就是后一条指令要用前一条还没算出来的结果。经典例子：

add x1, x2, x3 # x1 = x2 + x3 sub x4, x1, x5 # x4 = x1 - x5，x1 还没写回

add 的结果要到 WB 阶段才写进寄存器堆，而 sub 在 ID 阶段就要读 x1，中间差了三个周期。如果什么都不做，sub 只能等。

最常用的补救手段是前递（Forwarding / Bypassing）——ALU 算完的结果其实在 EX 阶段末就已经在 EX/MEM 流水线寄存器里了，没必要非得绕一圈等写回。直接在硬件上拉一条线，把 EX/MEM 或者 MEM/WB 里的值送回下一级指令的 ALU 输入端，就能让 sub 不必等待。

不过前递只能把停顿从三个周期压缩到一个，相邻的两条 ALU 指令可以完全不停。因为 add 在 EX 阶段末产出结果，sub 的 EX 阶段恰好比 add 晚一个周期，此时结果已经在 EX/MEM 寄存器里躺好了，直接前递即可。

表格看一下不同情况下的停顿需求：

这张表是 CPI 计算的核心，我做过的手算题里八成都在考"相邻 load 停顿一拍"这一条。

4.3 控制冒险：分支预测的两条路线

控制冒险来自分支跳转——处理器在 IF 阶段取下一条指令的时候，还不知道上一条分支到底跳不跳，取错了就白取。

最简单的是静态预测，比如"总是不跳"，遇到循环时前半段几乎全猜错；好一点的用 BTFN（Backward Taken, Forward Not Taken），因为向后跳通常是循环回边，跳的概率大；再进一步就是延迟槽，把跳转后面那一条不受分支影响的指令提前塞进来执行，MIPS 里的延迟槽就是这个思路的产物。编译器填不满延迟槽的时候，塞 NOP 也行。

动态预测才是现代处理器的标配。最低配是 1 位预测器，记录上次跳没跳，下次就猜一样，缺点是循环退出时会连错两次。改进成 2 位饱和计数器后，循环退出只错一次：

更复杂的还有两级自适应预测器，用一个分支历史寄存器去索引模式历史表，能识别出"前两次跳，这次就不跳"这类规律；再往上还有锦标赛预测器同时跑两个预测器取长补短，以及 TAGE 系列用多种历史长度做几何级数索引。实验室里那些预测准确率超过 97% 的成果，基本都出自这一类。

预测失败的代价要算清楚：五级流水线在 EX 阶段才能确定分支方向，此时已经有两条指令进入了流水线，所以失败时要冲刷掉两条，代价是 2 个周期。流水线越深，这个代价越大，这也是深流水线不受待见的核心原因。

4.4 三类冒险的处理手段汇总

乱序执行其实是数据冒险的终极解法——用寄存器重命名把 WAW 和 WAR 这两类假依赖彻底消掉，再配合保留站和重排序缓冲区让指令乱着执行、按序提交。这一步跨过去，就进入了现代超标量处理器的领域了，属于体系结构进阶内容，先把有序流水线吃透再说。

5. 动手写一个五级流水线模拟器

5.1 设计思路和数据结构

光看公式容易飘，我的习惯是把模型写成代码跑一遍，看看数字对不对得上。下面这个模拟器不追求完整，只保留冒险分析需要的信息：每条指令的目的寄存器、两个源寄存器、以及它是不是 load。

调度规则很朴素：指令按程序顺序进入 IF，默认每条比上一条晚一个周期；发射前检查它依赖的前几条指令，如果数据还没准备好，就把发射时间往后推。推进的量按前面那张表来算——ALU 结果在 EX 末可用，load 结果在 MEM 末可用，没有前递的话只能等 WB。

5.2 完整代码实现

class Instr: """一条指令的最小描述，只保留冒险分析所需字段。""" def __init__(self, name, rd=None, rs=None, rt=None, kind="alu"): self.name = name self.rd = rd # 目的寄存器，None 表示不写回 self.rs = rs # 源寄存器 1 self.rt = rt # 源寄存器 2（store 时存放待写数据） self.kind = kind # alu / load / store self.if_c = self.id_c = self.ex_c = self.mem_c = self.wb_c = None def simulate(prog, forward=True, verbose=True): """按序五级流水线调度，返回每条指令进入各阶段的周期号。""" scheduled = [] issue = 0 # 下一条指令最早能进 IF 的周期 for ins in prog: c = issue while True: # 推后之后可能又撞上更早的依赖，循环直到干净 bumped = False for prev in scheduled[-3:]: if prev.rd is None: continue if prev.rd in (ins.rs, ins.rt): if forward: # ALU 结果 EX 末可用；load 数据要等到 MEM 末 need = prev.mem_c + 1 if prev.kind == "load" else prev.ex_c + 1 else: # 无前递：只能等写回后再读，同周期内写在前、读在后 need = prev.wb_c + 1 if c + 2 < need: # c+2 是当前指令的 EX 周期 c = need - 2 bumped = True if not bumped: break ins.if_c, ins.id_c, ins.ex_c = c, c + 1, c + 2 ins.mem_c, ins.wb_c = c + 3, c + 4 scheduled.append(ins) issue = c + 1 cycles = max(i.wb_c for i in scheduled) + 1 ideal = len(scheduled) + 4 # 无任何冒险时的理论周期数 if verbose: print(f"forward={forward} 指令数={len(scheduled)} 总周期={cycles} " f"CPI={cycles / len(scheduled):.2f} 额外停顿={cycles - ideal} 拍") print(f"{'insn':<18}{'IF':>4}{'ID':>4}{'EX':>4}{'MEM':>4}{'WB':>4}") for i in scheduled: print(f"{i.name:<18}{i.if_c:>4}{i.id_c:>4}{i.ex_c:>4}{i.mem_c:>4}{i.wb_c:>4}") print() return scheduled if __name__ == "__main__": program = [ Instr("lw x1,0(x2)", rd="x1", rs="x2", kind="load"), Instr("add x3,x1,x4", rd="x3", rs="x1", rt="x4"), Instr("sub x5,x3,x1", rd="x5", rs="x3", rt="x1"), Instr("sw x5,4(x2)", rs="x2", rt="x5", kind="store"), Instr("add x6,x5,x1", rd="x6", rs="x5", rt="x1"), ] simulate(program, forward=True) simulate(program, forward=False)

代码不长，但把三类冒险里最容易考的数据冒险刻画完了。scheduled[-3:]只回看最近三条，是因为五级流水线里更早的指令早就写回完毕，不可能再对当前指令构成 RAW 依赖。

5.3 运行结果和解读

打开前递后跑一遍：

forward=True 指令数=5 总周期=10 CPI=2.00 额外停顿=1 拍 insn IF ID EX MEM WB lw x1,0(x2) 0 1 2 3 4 add x3,x1,x4 2 3 4 5 6 sub x5,x3,x1 3 4 5 6 7 sw x5,4(x2) 4 5 6 7 8 add x6,x5,x1 5 6 7 8 9

唯一的一拍停顿出现在lw和add之间。原因就是 load 的数据要到 MEM 阶段末（周期 3）才出来，而 add 的 EX 阶段如果按默认排到周期 3，就赶不上，只能推到周期 4，整个流水线被顶了一拍。后面的sub、sw、add x6全部靠前递搞定，零停顿。

把前递关掉：

forward=False 指令数=5 总周期=15 CPI=3.00 额外停顿=6 拍

CPI 从 2.0 涨到 3.0，整整多出五成。这就是前递硬件的价值所在——它省下来的不是一两个周期，而是整条流水线一半以上的停顿。

注意：这里的 CPI 是"单条流水线、无分支"的理想化数值。真实程序里还有分支预测失败、Cache 缺失等一大堆因素，实测 CPI 通常在 1.5 到 4 之间浮动，具体看程序访存模式。模拟器给出的只是数据依赖这一项的贡献。

如果想观察编译器调度的影响，可以把代码改成lw之后先插两条无关指令，再让add使用 x1，你会看到那一拍停顿凭空消失。这个现象叫软件流水或指令调度，编译器在生成代码时经常会做这件事，把有依赖的指令拉开距离，让硬件少停几拍。

6. 数据说话：不同策略下的 CPI 对比

6.1 实验设置与结果

把上面那个模拟器换几组测试程序，跑出来的 CPI 对比很能说明问题。我用了四个场景：全 ALU 无依赖、相邻 ALU 依赖、load 相邻依赖、load 隔两条依赖。

全 ALU 无依赖的场景下，前递就是个摆设，加不加周期数一样——这也解释了为什么有些简单处理器会省掉前递逻辑，用编译器调度来补。但只要有 load，前递的价值立刻显现，差距能达到 33%。

load 隔两条依赖这一行特别有意思：即使没有前递，CPI 也只要 2.0。因为中间两条无关指令天然把时间差抹平了。这给编译器优化指了条明路——与其硬着头皮堆硬件前递，不如在代码生成阶段把 load 尽量提前，把消费者推后。

6.2 分支预测失败的影响有多大

把分支加进去，情况会变得更复杂。五级流水线在 EX 阶段才能确定分支方向，失败时要冲刷两条已经进入 IF 和 ID 的指令。假设分支指令占比 20%，预测准确率 90%，那么：

• 每 100 条指令里有 20 条分支
• 其中 2 条预测失败
• 每条失败浪费 2 个周期
• 额外开销 = 2 × 2 ÷ 100 = 0.04 个 CPI

看着不多？把准确率换成 70%（新手写的预测器水平）：

• 6 条失败，额外开销 = 6 × 2 ÷ 100 = 0.12 个 CPI

如果分支占比提高到 30%，准确率还是 70%，额外开销涨到 0.18 个 CPI，相对基础 CPI 1.0 来说就是 18% 的性能损失。分支预测不是锦上添花的东西，它在分支密集的程序里能决定整机的性能档位。

再叠加流水深度的影响。假设流水线加深到 12 级，分支确定要等到第 8 级左右，失败时冲刷 7 条指令，每条失败浪费 7 个周期。同样的分支密度和准确率下，额外开销 = 6 × 7 ÷ 100 = 0.42 个 CPI，直接吃掉四成性能。这就解释了为什么深流水线必须配超强的分支预测器，两者是绑定的。

提示：算这类题目时，先把"基础 CPI + 数据冒险停顿 + 分支浪费"分开算，最后相加。混在一起算很容易漏项，特别是分支那条，很多人只记得乘预测失败率，忘了还要乘失败代价。

7. 常见问题与排查实录

7.1 高频问题速查表

这张表里的每一行，我都至少踩过一次。

7.2 几个文档里不会写的坑

第一个坑：把"理想 CPI = 1"当成默认值。很多教材推导时直接用 CPI = 1，导致做题时下意识认为流水线的 CPI 就是 1。实际上只要程序里有 load 依赖或者分支，CPI 就必然大于 1。我在做模拟器之前，一直以为五级流水线的 CPI 应该接近 1，跑出来 2.0 的时候愣了半天，后来才明白是 load-use 那一拍拖的后腿。

第二个坑：忽略寄存器堆的读写在同周期内可以共存。无前递场景下算停顿的时候，很多人会保守地认为"必须要等下一个周期才能读"，于是多停一拍。正确规则是：同一周期内写口在前半周期完成，读口在后半周期取值，所以生产者的 WB 阶段和消费者的 ID 阶段可以在同一个周期。这一条能让你的答案少错一拍，而往往就是这一拍决定对错。

第三个坑：分支延迟槽不是万能的。延迟槽的本意是让编译器找一条无论如何都要执行的指令填进去，但实际程序里能填满的比例并不高，很多情况下只能塞 NOP，反而浪费了一个指令槽。这也是后来 MIPS 和 SPARC 在新版本里逐步淡化延迟槽的原因。做题时如果题目没说"编译器能完美填充延迟槽"，就别假设它是免费的。

第四个坑：Cache 缺失和流水线停顿是两个独立维度，别混着算。流水线的停顿来自数据依赖和分支，Cache 缺失的代价来自访存层次。两者都会拉高 CPI，但机制不同，公式也不一样。我见过有人把 Cache 缺失率直接乘进流水线停顿里，结果数字离谱。正确做法是分别算出各自的平均周期贡献，最后相加。

第五个坑：流水线寄存器的开销别忘。做"加深流水线性能提升多少"的题目时，如果题目给了寄存器建立时间，一定要加进每级周期里。忘掉这一步，加速比会算得过于乐观，而且流水级数越多，误差越大。

第六个坑：确认题目到底考不考结构冒险。如果题目说的是"分离指令和数据存储器"，那 IF 和 MEM 的冲突就不存在，别自己加戏。反之，如果只提"统一的存储器"，那每一对 IF/MEM 重合的指令都要停一拍。我在这上面丢过分，因为没仔细看那句看似不起眼的描述。

8. 复习这块内容时我自己的几个习惯

我一般不推荐死磕教材的推导，效率太低。我的做法是先手推一遍五级流水线的时序表，把每条指令落在哪个周期画成表格，然后用前面那段代码验证一遍，两边对上了，说明理解没跑偏。对不上的时候，差异点通常就是我理解有偏差的地方，比盲目刷题有效得多。

再一个经验是，准备考试或者面试时，把三类冒险的处理手段各自背一个数字：结构冒险里的 IF/MEM 冲突要停几拍、数据冒险里 load-use 要停几拍、控制冒险里预测失败要冲刷几条。这三个数字记住了，80% 的计算题都能拆解出来。剩下的 20% 是各种组合变形，靠的就不是背，而是把模拟器那种"逐周期推演"的习惯练熟——一行一行推，不跳步，基本不会错。

国内几本常见的教学辅导书，比如胡伟武老师那本《计算机体系结构教学与习题指导》，习题覆盖面很广，其中流水线部分的题我建议挑十道精做，做完对照自己手推的时序表，看看哪里想当然地省了周期。很多高校的体系结构课程期中考也喜欢从这类题里变形出题，把"理想流水线"的假设去掉一个，看你还算不算得对。

最后一个观察：这块内容的价值不在于考试，而在于它建立起的一套思维方式——任何加速手段都有代价，所有性能数字都是乘法关系。前递快，但要额外布线；流水线深，但冒险代价高；Cache 大，但访存慢。把这种"到处是权衡"的直觉养起来，以后看任何性能优化问题，第一反应都会是"省了多少、花了多少、边界在哪"。