1. Y86-64 到底是个什么东西，为什么值得花时间

第一次翻到 CSPP 第 4 章的时候，我的第一反应是"这玩意儿是不是写错了页码"。前三章还在讲补码、汇编、链接这些能直接上手的东西，突然之间冒出个 Y86-64 指令集，配上一堆 HCL 代码块，最后还要你把一条五级流水线拼出来。当时我的处理方式是快速扫一遍，标记"以后再看"，然后翻到第 5 章去调程序性能。结果第 5 章讲到循环展开、减少数据依赖、分支预测失败代价的时候，我发现自己只会背结论，完全说不清"为什么展开就能快"。

后来老老实实回头把这一章啃完，动手写了顺序版的 SEQ，又把流水线补齐，才明白这一章在整个课程里的位置：它是一条分界线，前面教你"程序在机器上长什么样"，后面教你"机器为什么这么跑得快或者这么跑得慢"。Y86-64 就是这两半之间的桥——一个精简到可以手写、又完整到包含真实处理器所有核心机制的指令集架构。它保留寄存器、条件码、内存、跳转、函数调用、栈操作这些要素，把流水线的五个阶段、数据冒险、控制冒险、转发、气泡、异常一个个摊开给你看。

适合谁来读？我的判断是三类人。第一类是正在学这门课、被第 4 章卡住的学生，尤其是被 HCL 和流水线控制逻辑绕晕的那批；第二类是工作几年后发现"性能调优全靠猜"的开发者，想补上从指令到硬件的这一环；第三类是对底层好奇、但被真实指令集的复杂度劝退的人。这篇笔记按我自己的理解顺序走：状态模型、指令编码、顺序实现、五级流水线、配套实验、踩坑记录，中间会穿插一些我在写控制逻辑时踩过的坑，以及一些教材里一句话带过、但不动手就永远意识不到的细节。

1.1 从"会读汇编"到"能设计一台能跑汇编的机器"

前几章的训练目标是"读懂"：给你一段汇编，你能说出它改了什么寄存器、访了哪块内存、跳到了哪里。第 4 章的目标换了，是"造出来"：给你一条指令，你要能把它拆成取指、译码、执行、访存、写回几个动作，然后设计出一套数据通路和控制信号，让这套动作在一个时钟周期里按顺序发生。

这个转变的难点不在于概念多，而在于你必须同时持有两个视角。一个是软件视角：addq %rax, %rbx就是把两个寄存器加起来。另一个是硬件视角：这条指令要先从指令内存里取出 2 个字节，把高 4 位和低 4 位分别当成两个寄存器编号，送到寄存器文件的两个读端口，读出来的值送进 ALU，ALU 做完加法把结果送回寄存器文件的写端口，同时根据结果更新三个条件码。两个视角必须能自由切换，看汇编的时候能想到电路，看电路的时候能想到指令。

我自己的经验是，卡住的时候先别看 HCL，拿一张纸把某条指令的字节画出来，一个字节一个字节地标注"这一段是干什么的"。比如mrmovq 8(%rbx), %rax，10 个字节里，第一个字节拆成 icode=5、ifun=0，第二个字节拆成 rA=0（%rax）、rB=3（%rbx），后面 8 个字节是常数 8。这样过一遍，再看译码阶段"要从哪读、要往哪写"，逻辑会顺很多。

1.2 砍掉的那些东西，才是它好用的原因

很多人第一次接触 Y86-64 会有一个疑问：这东西是不是太玩具了，学了有什么用。我的看法正好相反，它的价值恰恰来自"被砍掉的部分"。真实处理器指令集动辄上千条指令，编码长度从 1 字节到十几字节不等，寻址模式有七八种组合，还带着各种历史包袱。你让一个初学者在这样的复杂度里找"流水线"这个主干，等于让人在一片森林里找一棵特定的树。

Y86-64 的取舍非常明确，下面这张表是我自己整理的对照，能看出哪些是"故意留着的难点"，哪些是"故意去掉的噪音"。

关键在于，被保留的那部分没有一个是"简化版假货"。五个阶段的划分是真的，变长指令取指的边界问题是真的，数据冒险和转发路径是真的，分支预测失败要清空流水线也是真的。你把 Y86-64 的流水线搞懂了，再去看任何一款处理器的流水线框图，结构上都能对上号，只是每一级更宽、更复杂、并行度更高。

1.3 学完这一章，影响会辐射到哪里

我不太喜欢"学这个是为了以后"这种说法，但这一章确实是个例外，因为它的影响范围很具体。

最直接的辐射是第 5 章的程序性能优化。那一章会讲循环展开、消除不必要的函数调用、减少数据依赖、提高指令级并行。如果你脑子里有一条五级流水线，就会知道循环展开不只是"少执行几次跳转"，更重要的是减少控制冒险带来的流水线清空；消除依赖也不只是"少读一次寄存器"，而是让相邻指令能真正在流水线上并行推进，而不是互相等待。

第二层辐射是存储层次。流水线的访存阶段是整条流水线上延迟最大、最容易卡住的一环，加载指令后面紧跟一条使用它的指令，就必须停一拍。这个"加载/使用冒险"的代价，是理解为什么缓存命中率如此重要的最直观入口。

第三层辐射是日常写代码的习惯。写过一遍转发逻辑，再看那些"先算地址再解引用"的代码，你会本能地想到能不能把地址计算提前、把访存和使用拉开距离；写过一遍分支预测错误的处理，再看密集的条件分支，你会知道为什么有时候把条件改成算术运算反而更快。这些都不是玄学，是流水线的物理特性投射到代码上的结果。

2. 先搞清楚机器"记得住"什么：状态模型与指令编码

设计一台机器之前，得先定义这台机器要"记住"什么。这个思路很像写一个类之前先定义它的成员变量：状态确定下来，所有指令的语义就变成了"如何读写这些状态"。Y86-64 的状态集合非常小，小到你可以把整台机器画在一张 A4 纸上。

2.1 四类可见状态，一条也不能漏

第一类是程序寄存器。Y86-64 有 15 个通用寄存器，编号 0 到 14，分别是 %rax、%rcx、%rdx、%rbx、%rsp、%rbp、%rsi、%rdi，再加 %r8 到 %r14。编号 15 是个特殊值，表示"没有寄存器"，写作 RNONE。这个约定非常重要，比如irmovq的源操作数是立即数，不需要读寄存器，编码时就把 rA 填成 0xF；popq的源是栈顶内存，不读寄存器，也是一样处理。我见过不少人在这里卡住，原因是下意识觉得"总得有个寄存器编号"，结果 HCL 里的判断条件怎么写都不对。

第二类是条件码，ZF、SF、OF 三个，分别表示最近一次算术运算的结果是否为零、是否为负、是否溢出。这里有个容易被忽略的规则：条件码是被"算术逻辑指令"更新的，跳转指令和传送指令不更新。而且更新是在写回阶段发生的，这一点在流水线里会引出很微妙的问题，后面讲条件传送的时候会详细说。

第三类是程序计数器 PC，存放下一条要执行指令的地址。第四类是内存，一个很大的字节数组，按小端序存放多字节数据。除了这四类，还有一个状态码 Stat，用来表示当前指令的执行情况，取值包括正常、停机、地址错误、非法指令。

注意：Y86-64 的寄存器是 15 个而不是 8 个，这一点在早期的 Y86 和 Y86-64 之间是有区别的。写 HCL 时如果用rA in {0..7}这种范围判断，会漏掉 %r8 到 %r14，症状是高位寄存器的指令行为诡异但又不报错，非常难查。

2.2 指令编码里的三个规律

Y86-64 的指令编码不是随意排的，它遵循三个很有规律的约定，理解了这三个约定，那张指令表就不需要背。

第一个规律：所有指令都以一个字节的指令码 icode 开头，紧接着是一个字节的功能码 ifun。icode 决定"这是哪一类操作"，ifun 决定"这一类里的哪一个"。比如 icode=6 是算术逻辑类，ifun=0 是加法、1 是减法、2 是与、3 是异或；icode=7 是跳转类，ifun 从 0 到 6 分别对应无条件跳转、小于等于、小于、等于、不等于、大于等于、大于。

第二个规律：需要读写寄存器的指令，第二字节拆成两个 4 位字段，高 4 位是 rA，低 4 位是 rB。这里有个细节值得注意：rrmovq和cmovXX共用 icode=2，靠 ifun 区分，ifun=0 是无条件传送，1 到 6 对应六种条件。这种"同码不同功能"的设计在真实指令集里很常见，好处是译码阶段可以共用大部分逻辑。

第三个规律：需要常数字的指令，常数字固定占 8 个字节，紧跟在寄存器字节后面。所以指令长度只有四种：1 字节（halt、nop、ret）、2 字节（rrmovq、cmov、OPq、pushq、popq）、9 字节（jXX、call）、10 字节（irmovq、rmmovq、mrmovq）。没有对齐要求，没有前缀，没有 ModRM 那一套，取指逻辑因此可以写得非常干净。

下面这张表是我自己默写过好几遍的，建议也默写一遍，写的过程中你会发现哪些地方记混了。

2.3 手把手算一遍指令字节

只看表不动手，永远记不牢。我建议拿三条指令各算一遍，算完你对取指阶段的理解会立刻不一样。

第一条，irmovq $0x1234, %rax。icode=3，ifun=0，rA=0xF（因为源是立即数，没有源寄存器），rB=0（%rax 的编号），常数字是 0x1234，小端序存成34 12 00 00 00 00 00 00。合起来十个字节是30 f0 34 12 00 00 00 00 00 00。这道题的关键是记住 rA 必须填 f，很多人下意识填成 0，编码就错了。

第二条，rmmovq %rax, 8(%rbx)。icode=4，ifun=0，rA=0（%rax 是数据源），rB=3（%rbx 是基址），常数字是 8。十个字节是40 03 08 00 00 00 00 00 00 00。注意这里的语义：rA 是"要写出去的值"，rB 是"地址的基址"，常数字是偏移。执行阶段要做的是把 rB 的值加上常数字得到地址，这解释了为什么 ALU 输入要接常数字和寄存器值。

第三条，jmp 0x100。icode=7，ifun=0，后面直接跟 8 字节目标地址，共 9 个字节：70 00 00 01 00 00 00 00 00。注意这里少一个字节，因为跳转指令不涉及寄存器，没有那一字节的寄存器字段。这一点在计算 valP 的时候特别容易出错，如果你的取指逻辑统一按 10 字节算，跳转之后的所有指令地址都会错位。

提示：写汇编或者手动编码时，先在心里过一遍"这条指令有没有寄存器字节、有没有常数字节"，再决定长度。养成这个习惯，后面算 valP、判断指令边界的时候能省掉大量调试时间。

3. 顺序实现：一条指令是怎么被"走"完的

顺序实现（SEQ）的定位很明确：它不是最快的，但它是最容易验证正确的。它把每条指令拆成六个阶段，全部塞进一个时钟周期里串行完成。你可以把它理解成一条只有一个工位的流水线，工人把一件产品的所有工序从头做到尾，做完一件再做下一件。

3.1 六个阶段的分工

取指阶段从指令内存读字节，先读 1 个字节拿到 icode，根据 icode 决定要不要再读 1 个字节的寄存器字段、要不要再读 8 个字节的常数字。同时计算 valP，也就是"这条指令之后的下一条指令地址"。这个阶段最核心的两个输出是当前指令的各个字段和 valP。

译码阶段从寄存器文件读操作数。这里要注意，读哪两个寄存器不是固定的，而是由 icode 决定的：算术逻辑指令读 rA 和 rB，内存写指令读 rA 和 rB，内存读指令只读 rB，压栈读 rA，出栈和返回读 %rsp，调用读 %rsp。所以译码阶段的第一个任务其实不是读，而是"算出该读谁"，也就是生成 srcA 和 srcB 两个信号。

执行阶段用 ALU 做运算。访存阶段读写数据内存。写回阶段把结果写进寄存器文件，同时更新条件码。更新 PC 阶段决定下一条指令的地址：正常情况下是 valP，跳转和调用是 valC，返回是从内存里读出来的返回地址。

这六个阶段串起来就是 SEQ 的全部。没有流水线寄存器，没有冒险，没有气泡，所有信号都是组合逻辑直接连通的。写起来很直观，但你会立刻发现一个问题：这么多东西串在一个周期里，时钟周期得拉多长？

3.2 一套 ALU 打通所有算术

第一次看 SEQ 的 ALU 输入选择，我愣了很久：为什么地址计算、栈指针调整、立即数传送这些看起来毫不相干的操作，全都走同一个 ALU？

想通了之后就明白这是数据通路复用的经典手法。一台机器上需要"做加法"的地方太多了：算术指令要加，访存要算地址，压栈要减 8，出栈要加 8，调用要减 8 并写返回地址，返回要加 8。与其给每个地方配一个加法器，不如配一个通用的 ALU，然后用两组多路选择器决定"两个输入分别取什么"，用功能码决定"做哪种运算"。

具体来说，ALU 的 A 输入根据指令类型选择：算术指令取寄存器 A 的值，立即数传送取常数字，内存读写取常数字，压栈和调用取 -8，出栈和返回取 8。B 输入也有类似的规则：算术和访存取寄存器 B 的值，立即数传送取 0，压栈、调用、出栈、返回都取 %rsp 的值。

这套规则记不住怎么办？我的办法是只想一个问题："这条指令需要算出来的那个数，是由哪两个数加出来的？"rmmovq需要算地址，地址 = 基址 + 偏移，所以是 rB + valC。pushq需要算新的栈指针，新栈指针 = 旧栈指针 - 8，所以是 %rsp + (-8)。这样一条条推，比背表靠谱得多。

3.3 HCL：描述硬件的一种"接口语言"

HCL 看起来像代码，其实它不是程序，是电路的描述。这一点如果搞混，后面会吃大亏。HCL 里的每个表达式都对应一组组合逻辑门，没有"执行顺序"，没有"循环"，没有"变量赋值"，只有"根据输入算出输出"。

最基本的两种写法是布尔表达式和选择表达式。布尔表达式用&&、||、!组合，选择表达式用方括号包起来的一系列"条件 : 结果"对，从上往下匹配，第一个为真的条件生效，最后的1 :是默认项。

举个最容易上手的例子，译码阶段的源寄存器选择：

word srcA = [ icode in { IRRMOVQ, IRMMOVQ, IOPQ, IPUSHQ } : rA; icode in { IPOPQ, IRET } : RRSP; 1 : RNONE; ];

读法是这样的：如果当前指令是条件传送、内存写、算术或者压栈，源寄存器 A 就是指令里的 rA 字段；如果是出栈或者返回，源寄存器 A 是栈指针；其他情况没有源寄存器 A。这个写法没有"else if"的概念，就是一组并行的条件判断，最后兜底。

in这个关键字是 HCL 特有的集合成员判断，等价于一串或运算。用它的好处是可读性，而且综合成电路的时候就是一排或门，没有语义歧义。

注意：HCL 的选择表达式是"从上往下、首个匹配"，不是"最后一个匹配"。这一点和很多语言的 switch 不同，写反了不会报错，只会得到错误的结果，而且错误往往表现得非常隐蔽。我第一版写转发逻辑时就写反过一次，现象是某些指令偶尔读到旧值，找了两个小时才发现是把优先级顺序弄颠倒了。

3.4 SEQ 的 CPI 是 1，但别急着高兴

这里有个非常常见的误解，我自己也犯过：看到六个阶段串行执行，就以为 SEQ 的 CPI 是 5 或者 6。实际上教材里的 SEQ 是把六个阶段全部放在一个时钟周期内完成的，所以每条指令占一个周期，CPI 等于 1。

那为什么还要流水线？因为衡量性能不能只看 CPI，还要看时钟周期有多长。SEQ 的时钟周期必须长到能容纳"取指 → 译码 → 执行 → 访存 → 写回 → 更新 PC"这条最长路径的全部延迟，其中取指要读指令内存、译码要读寄存器文件、执行要过 ALU、访存要读数据内存，每一段都有实打实的门延迟。把这条路径切成五段，每段只在流水线寄存器之间跑一小截，时钟周期就能缩短到原来的五分之一左右（理想情况下），于是同样的 CPI 换来高得多的主频。

这个账要算清楚：性能 = 指令数 × CPI × 时钟周期。流水线不改变指令数，理想情况下也不改变 CPI，它改变的是时钟周期。而一旦出现冒险，CPI 会大于 1，这时候就要拿"缩短的时钟周期"和"增加的 CPI"做权衡。第 5 章讲优化的时候，本质上就是在做这个权衡。

4. 五级流水线：把时钟周期切成五份

流水线的思想本身不复杂，生活里的类比一抓一大把：洗车房分成冲水、打泡、擦洗、烘干四道工序，四辆车同时在线上，每道工序由一个工位负责，理论上一辆车洗完就出一辆。难点不在思想，在于"同时"这两个字带来的所有麻烦。

4.1 流水线寄存器和阶段的重新划分

从顺序实现改成流水线，第一件事是把"更新 PC"合并进取指阶段，于是六个阶段变成五个：取指、译码、执行、访存、写回。之所以能合并，是因为更新 PC 的逻辑本来就在取指阶段的末尾，把它挪进取指不改变语义。

第二件事是在每两级之间插入流水线寄存器，把上一阶段的输出锁存下来，供下一阶段使用。这一步是整个改造的核心，因为寄存器一插，原本"组合逻辑直接连通"的关系就断了，上一阶段的信号在这一周期结束后才能被下一阶段看到，这就是流水线能并行的物理基础，也是所有冒险的来源。

流水线寄存器里的字段很多，但不用死记，按阶段分组理解就行。取指和译码之间的寄存器主要保存预测的下一条 PC、当前