Y86-64处理器设计：从HCL到SEQ/PIPE流水线

第一次翻到第 4 章的时候,看到 Y86-64 那一堆寄存器名、状态码、HCL 代码和六个阶段的数据通路图,我的第一反应是"这玩意儿跟写代码有什么关系"。真正上手做完实验之后才明白,这一章是整个课程里唯一一处把"你写的一行 C 语句"和"CPU 内部那根时钟线上的电平"接上的地方。Y86-64 是一个刻意做小的指令集,小到你能在一个下午里把它的所有指令背下来,小到你能用几百行 HCL 把整个处理器描述完;但它又不是玩具,它有条件码、有栈、有函数调用、有内存寻址,该有的都有。这一章讲的其实不是某颗具体的芯片,而是一套方法论:把一个处理器拆成组合逻辑 + 时钟状态两部分,再沿着取指、译码、执行、访存、写回、PC 更新六个阶段滚一遍,最后把这条"单周期"的路径切开、插上流水线寄存器,让它每个周期都能吐一条指令。不管你后面是做嵌入式、做性能优化,还是纯粹想把体系结构的底子打牢,这套东西都是绕不开的。下面我按自己的学习顺序,把这一章里真正需要理解的点和实际做实验时踩过的坑,一条一条捋出来。

1. 为什么要花时间啃一个"不存在的指令集"

1.1 从高级语言到时钟沿之间,缺了一层

绝大多数人学编程的过程是断层的:上面是 C、Python、Go,下面是"CPU 很厉害,一秒几十亿次"。中间那层——指令怎么编码、操作数从哪来、结果写回哪里、下一条指令的地址怎么算——基本是空白。空白带来的直接后果是,很多性能问题你只能靠"猜"。为什么这个循环比那个快?为什么这个结构体访问有开销?为什么分支多的代码在某些机器上表现更差?没有这一层认知,你只能在经验层面打转,而有了这一层,你能自己推出结论。

Y86-64 的价值就在于它把这层空白填上了,而且填得足够窄。真实的 x86-64 指令集有上千条指令、几十种前缀、复杂的寻址模式,你想"整体把握"几乎不可能。Y86-64 只有十来条,寄存器八个常用的,寻址模式就那一种D(rB),你可以在纸上把它整个跑一遍。理解了它之后,再去看真实处理器的那些扩展——乱序执行、多发射、分支预测器、缓存层次——你会发现它们都是在同一个骨架上加东西,而不是另起炉灶。

1.2 它刻意丢掉了什么,又刻意保留了什么

这一点很多人没意识到,但非常关键。Y86-64 丢掉的东西:大量指令、复杂寻址、浮点、向量。这些都是"规模问题",不影响你对处理器工作原理的理解。Y86-64 保留的东西:寄存器堆、条件码、程序计数器、指令内存与数据内存、栈、函数调用与返回、跳转与条件传送。这些是"结构问题",缺一个你的理解模型就是残的。

尤其值得注意的是它保留了条件码(ZF、SF、OF)。现代 RISC 架构倾向于不要条件码,但你只要写过汇编就知道,cmp+jle这套组合是最自然的控制流表达方式。保留条件码意味着你必须处理"条件码在什么时候被写入"这个问题,而这个问题的答案在流水线里会变成一个真实的冒险:一条算术指令写完条件码,紧跟一条条件跳转要用它,你怎么办?这就是后面控制冒险那一节的核心。

1.3 先建立一张全局地图,别急着写代码

我的建议是,在动手改任何一行 HCL 之前,先在纸上画三张图。第一张是状态图:程序计数器 PC、寄存器堆、条件码、内存、状态码 Stat,这五样东西是跨指令存在的状态,其余全是每个周期重算一遍的组合逻辑。第二张是数据流图:指令字节进来到结果写回,中间经过哪几个选择器(MUX)、哪几个算术单元。第三张是时间线图:一条指令在 SEQ 里占用整个周期,在 PIPE 里分散到五个周期,画出来你才知道"冒险"到底是在哪两个周期之间发生的。

这三张图画完,你会发现后面所有的复杂度都来自同一个矛盾:你希望每个周期都完成一条指令(为了吞吐率),但一条指令的六个阶段都依赖彼此的数据。把这个矛盾想清楚,流水线那一节就不是死记硬背了。

2. 指令集本身:先把"这台机器认识什么"搞明白

2.1 五个状态元素就是 CPU 的全部"记忆"

Y86-64 的状态只有五样,列出来之后你会觉得处理器没那么神秘了:

注意 0xF 这个编号的特殊含义:它表示"没有寄存器"。任何指令里如果某个寄存器字段是 0xF,译码阶段就该把它当成"不读"或"不写"。这个设计非常省事,它让你不用为每条指令单独写一套译码逻辑,统一按"读 srcA/srcB、写 dstE/dstM"处理,不需要的时候填 0xF 就行。

还有一点容易忽略:条件码只在执行阶段被某些指令修改。OPq类指令会写,ZF/SF/OF 都更新;cmov和jXX只读不写;其余指令既不读也不写。这个"谁写谁读"的约定如果不清楚,后面写 HCL 的时候set_cc那个信号一定会写错。

2.2 指令编码:高 4 位是"干什么",低 4 位是"怎么干"

Y86-64 的每条指令第一个字节拆成两半:高 4 位是icode(指令代码),低 4 位是ifun(功能码)。这个设计很聪明,它把"大类"和"变体"分开了:

• 0x6是OPq,后面跟的功能码 0/1/2/3 分别代表 add/sub/and/xor;
• 0x7是jXX,功能码 0–6 分别是 jmp/jle/jl/je/jne/jge/jg;
• 0x2是cmovXX,功能码同样是 0–6。

好处是执行阶段的 ALU 只需要看ifun,译码阶段的寄存器选择只需要看icode属于哪一族,两者解耦。这一点在你写 HCL 的时候会体现得特别明显:ALU 的ALUfun信号几乎是直接从ifun拉过来的。

长度的差异是新手第一个坑。irmovq是 10 字节,因为要装一个 8 字节立即数;jXX是 9 字节,因为目标地址是 8 字节。取指阶段必须根据icode算出valP = PC + 指令长度,这个长度不是固定的,得用一张表或者一段 HCL 逻辑算出来。

2.3 手算几条机器码,比看十遍图都管用

理解编码最快的方式是自己手写几条,再用汇编器验证。举一个最经典的例子,把%rax里的值加 8:

irmovq $8, %rbx # 3 0 f 3 08 00 00 00 00 00 00 addq %rbx, %rax # 6 0 3 0

第一行是irmovq,icode=3、ifun=0、rA 填 F(无源寄存器)、rB=3(%rbx),后面跟 8 字节立即数08 00 ...,小端序。第二行是OPq的 add,icode=6、ifun=0、rA=3、rB=0,意思是%rax = %rax + %rbx。注意 Y86-64 的OPq语义是rB = rB OP rA,源在左、目标在右,和 AT&T 语法的书写顺序刚好是反的,这个也是坑。

验证的最快方式是写一个.ys文件,用yas汇编成.yo目标文件,再打开看。.yo是文本格式,里面每条指令后面都跟着十六进制字节,和你在纸上算的对照一下,错在哪一步立刻就能发现。

# 汇编 + 反汇编,形成闭环验证 ./yas example.ys ./yis example.yo # 想看得更细就用模拟器逐周期输出 ./sim -i example.yo

提示:yis是指令集模拟器,只解释执行;sim是周期级模拟器,会按 SEQ 或 PIPE 的阶段打印每个信号。两者的用途完全不同,前者验证语义对不对,后者验证你的 HCL 写得对不对。

3. HCL:用布尔表达式描述一块电路

3.1 它看起来像编程语言,但根本不是

HCL 是这门课自己设计的一种硬件控制语言,它最容易被误用的地方在于:它没有赋值,只有连接。你写的每一行bool x = ...或者word y = [...]描述的是一条始终存在的导线,而不是"程序执行到这一行时把值赋给变量"。这个差别听起来抽象,但踩过坑就懂了。

比如你想表达"如果是 irmovq,ALU 的 A 输入用立即数,否则用 valA",正确的写法是一个选择表达式:

word aluA = [ icode in { IRRMOVQ, IOPQ } : valA; icode in { IIRMOVQ, IRMMOVQ, IMRMOVQ } : valC; icode in { ICALL, IPUSHQ } : -8; icode in { IRET, IPOPQ } : 8; ];

这段的意思是:一个多路选择器,输入是四个候选值,选择信号是icode。注意最后一行没有条件,它是默认分支,相当于default。所有可能的情况必须被覆盖,否则综合出来的电路在未定义输入下行为不可预测——这也是为什么每个[...]块都以一个无条件分支结尾。

3.2 组合逻辑和时序逻辑的边界必须划清

HCL 里只有两类东西:bool/word这样的组合逻辑,描述"输出是输入的函数,与时间无关";和寄存器,描述"在时钟上升沿把输入打进输出"。前者的求值不需要时钟,后者的更新只在时钟沿发生。整个处理器就是这两东西按层次拼起来的。

这个边界一旦混淆,调试会非常痛苦。我见过一种典型错误:有人想在 HCL 里"保存"一个中间结果,于是写了个word tmp = ...,后面又在别处试图修改它。HCL 不支持这个,tmp每时每刻都是它那个表达式的值。真要保存,只能放进流水线寄存器。

3.3 那个经典的坑:把"选择"写成"如果"

初学者写 HCL 最容易犯的错,是把它当 if-else 语句写,顺序写反。[ ... ]块里的匹配是从上到下优先的,第一条匹配的条件生效。所以写set_cc的时候:

bool set_cc = icode in { IOPQ, IIADDQ };

这行是正确的,因为只有算术指令才更新条件码。但如果你写成icode != IHALT,就会导致rrmovq这类指令也去动条件码,后面的jXX全部行为异常。这类 bug 不会报错,只会让你在测试用例里看到莫名其妙的分支走向。

我的经验是:每写一个选择块,先在注释里用自然语言把"什么情况下选什么"列一遍,再翻译成 HCL,最后用一张真值表手工核对两三个边界情况。这个习惯能省掉大量后期调试时间。

4. SEQ:一个周期干完一条完整指令

4.1 六阶段的划分逻辑

SEQ 是最直观的实现:每个时钟周期,把取指、译码、执行、访存、写回、PC 更新六个阶段全部走完,周期结束时把新状态打进寄存器。它慢,但正确性容易验证,是理解整个处理器的起点。

这六个阶段为什么要这样分?因为它们对应的是数据流上的自然断点:取指解决"指令在哪、有多长";译码解决"操作数从哪来";执行解决"算什么";访存解决"要不要碰内存";写回解决"结果去哪";PC 更新解决"下一条是谁"。每一段都只依赖前一段的输出,这让后面的流水线化变得可行——你可以把任意两个相邻阶段之间的边界切开,插一个流水线寄存器进去。

4.2 取指:PC 只有一个,但你得知道指令多长

取指阶段的输出有四个:icode:ifun、rA:rB、valC、valP。前两个从指令字节里拆,valC是 8 字节常数字段(可能是指令里的立即数、偏移量或者跳转目标),valP是下一条指令的地址。

valP的计算需要指令长度。Y86-64 里长度只有四种:1、2、9、10。写 HCL 的时候用一个选择块就能覆盖:

word valP = [ icode in { IHALT, INOP, IRET } : PC + 1; icode in { IRRMOVQ, IOPQ, IPUSHQ, IPOPQ, ICMOVXX } : PC + 2; icode in { IJXX, ICALL } : PC + 9; icode in { IIRMOVQ, IRMMOVQ, IMRMOVQ, IIADDQ } : PC + 10; ];

这里必须用无条件默认分支兜底,不然icode出现非法值(比如 0xD)的时候,valP没有定义,后面所有阶段都跟着乱。而这个非法值的处理恰好考的是Stat状态:

word stat = [ imem_error || dmem_error : SADR; !instr_valid : SINS; icode == IHALT : SHLT; 1 : SAOK; ];

优先级顺序很重要:访存错误 > 非法指令 > halt > 正常。为什么访存错误优先?因为如果取指本身就拿到了不存在的地址,你连指令是什么都不知道,谈不上"非法指令"。

4.3 译码与写回:srcA/srcB 和 dstE/dstM 的取值逻辑

译码阶段的活儿看着琐碎,其实是整个处理器里最容易出错的模块,因为它要区分"哪条指令从哪个字段读寄存器"。四条规则:

• rrmovq、OPq、rmmovq、cmovXX:srcA = rA;
• mrmovq、popq:srcA = %rsp(栈操作隐含读栈指针);
• pushq、call、ret:srcA = %rsp;
• 其余:srcA = RNONE。

srcB类似,但注意mrmovq、rmmovq、OPq、irmovq、iaddq都要读rB(作为基址或目标),而jXX、call、ret、pushq、popq的srcB是RNONE。

写回阶段决定dstE(ALU 结果写哪个寄存器)和dstM(内存读出的值写哪个寄存器)。关键点:pushq和call虽然有写回动作,但它们写的是栈指针,由 ALU 算出的%rsp - 8提供,所以dstE = %rsp;popq和ret同理,dstE = %rsp,同时popq还有dstM = rA。

我建议把这张对照表抄在一张纸上,写 HCL 时对着填,不要凭记忆。因为一旦dstE写错,寄存器内容会以一种极其隐蔽的方式错位——你可能要跑几十个测试用例才发现问题出在三个周期之前。

4.4 执行:ALU 的两个输入是怎么被"拼"出来的

执行阶段是整个数据通路里最像"电路"的一段,因为有太多分支。ALU 的 A 输入和 B 输入对不同的指令来自完全不同的地方:

• OPq:A =valA,B =valB;
• rrmovq/cmovXX:A =valA,B = 0;
• irmovq/iaddq:A =valC,B = 0;
• rmmovq/mrmovq:A =valC(偏移量),B =valB(基址);
• call/pushq:A = -8,B =%rsp;
• ret/popq:A = 8,B =%rsp。

写成 HCL 就是两个选择块。这里有个小细节:rrmovq和cmovXX用 ALU 只是为了把valA原样传过去,所以 B 填 0 做加法;irmovq用 A =valC、B = 0 也是同样的技巧。这种"借 ALU 做数据搬运"的思路在真实处理器里到处都是。

条件码的设置逻辑:

bool set_cc = icode in { IOPQ, IIADDQ };

只有这两类指令会更新 CC。cmovXX和jXX只读,irmovq之类的完全无关。这个set_cc在流水线版本里会变成一个麻烦:条件码在流水线的执行阶段产生,但如果后面紧跟一条cmov,它需要条件码的地方可能在译码之后、执行之前。这就是后面控制冒险要处理的问题之一。

4.5 访存和 PC 更新:优先级链是最容易写错的地方

访存阶段决定读不读、写不写:

bool mem_read = icode in { IMRMOVQ, IPOPQ, IRET }; bool mem_write = icode in { IRMMOVQ, IPUSHQ, ICALL };

注意call要写内存(把返回地址压栈),ret要读内存(从栈顶取返回地址),这两个很容易漏。

PC 更新阶段的选择块,我建议按"特殊情况优先"的顺序写:

word new_pc = [ icode == ICALL : valC; # 直接跳到目标 icode == IJXX && Cnd : valC; # 条件成立才跳 icode == IRET : valM; # 从栈里取 1 : valP; # 默认顺序执行 ];

Cnd是条件码的组合逻辑:

bool Cnd = [ ifun == 0 : 1; # jmp ifun == 1 : ZF || (SF ^ OF); # jle ifun == 2 : SF ^ OF; # jl ifun == 3 : ZF; # je ifun == 4 : !ZF; # jne ifun == 5 : !(SF ^ OF); # jge ifun == 6 : !(SF ^ OF) && !ZF; # jg ];

这一段我建议动手在纸上推一遍:为什么jl是SF ^ OF?因为有符号比较的本质是看减法结果的符号,但减法可能溢出,溢出时符号位翻转,所以要异或一下修正。推明白这个,jle、jge、jg的组合就是自然结论了。

5. 从 SEQ 到 PIPE:为什么"拆开"这么难

5.1 吞吐率和延迟是两件事

SEQ 的问题是:一条指令必须在同一个周期里完成全部六个阶段,而这个周期的长度必须能容纳最慢的那条路径(通常是访存)。这就导致时钟频率被最坏情况拖死,而大多数指令根本用不到那么长的路径。

流水线的思路是:在阶段之间插入流水线寄存器(F、D、E、M、W 五组),每个周期只做一段,做完就交给下一个寄存器。这样时钟周期只取决于最慢的那一段,而不是整条路径,频率能显著提高。代价是:单条指令的完成时间变长了(要经过五个周期),但吞吐率(单位时间完成的指令数)接近提升五倍。

这个权衡值得记在心里,因为它是所有性能优化的原型:吞吐率优先于延迟。后面你看到乱序执行、多发射,本质都是在这个方向上继续走。

5.2 流水线寄存器填什么,决定了你要处理多少冒险

这一步有个非常重要的技巧:在 SEQ 里,很多值是在某个阶段现算的,但在 PIPE 里不能现算,因为你算的时候依赖的那个寄存器可能已经被后续指令改掉了。所以 PIPE 的做法是:在译码阶段就把所有可能用到的值全部算好、塞进流水线寄存器,后面阶段只做选择,不做计算。

具体来说,valA、valB、dstE、dstM、srcA、srcB全都提前算好放进 E 寄存器,valE、valM、dstE、dstM放进 M 寄存器。多存几个字段,换来的是后面各阶段彼此独立。这个设计思想很值得学:用空间换时间,用冗余换并行。

5.3 数据冒险:转发不是万能的

数据冒险的定义很直白:后面一条指令要用前面一条指令还没写回的结果。比如:

addq %rax, %rbx # 结果在 E 阶段末尾才出来 rrmovq %rbx, %rcx # 但译码阶段就想读 %rbx

第二条指令读寄存器的时候,第一条的结果还在 ALU 里没写回去。转发(forwarding)就是把 ALU 的输出直接引到 ALU 的输入端,绕过寄存器堆:

word aluA = [ srcA == REG_RAX : e_valE; srcA == REG_RBX : M_valE; srcA == REG_RCX : m_valM; 1 : d_rvalA; ];

转发路径通常有四条:E→E、M→E、W→E,以及内存值 M→E。选择哪一条取决于"要用的寄存器编号"和"上一条指令的dstE/dstM是否相同"。这个比较逻辑写起来不难,但优先级顺序很关键:如果三条转发路径同时命中,应该选最新的那个,也就是 E 阶段的,因为它的值还没被后续指令覆盖。

注意:转发必须同时判断dst != RNONE。如果上一条指令的dstE是0xF(不写寄存器),你却因为编号比较相等就转发,会转发出垃圾数据。这个坑非常隐蔽,因为0xF恰好也是一个合法的 4 位值。

5.4 load-use 冒险:怎么转发都救不了的那一种

有一类冒险转发解决不了:mrmovq后面紧跟一条要用读出来的值的指令。

mrmovq 0(%rax), %rbx # 值要到 M 阶段末尾才从内存出来 addq %rbx, %rcx # E 阶段就要用,但此时值还没到

这时候无论怎么转发,时间上都来不及。唯一的办法是暂停一个周期(stall):让 E 阶段的指令停在原地,让 F/D 的指令也停住,同时往 E 里插一个nop(冒泡)。实现上,PIPE 会输出一个F_stall、D_stall、E_bubble的组合信号。

暂停逻辑的判据是:

bool load_use_hazard = (E_icode in { IMRMOVQ, IPOPQ }) && (E_dstM in { d_srcA, d_srcB });

注意这里必须包含popq,因为popq也从内存读值。而且判据里用in { d_srcA, d_srcB }这种集合写法,一次判断两个潜在的消费方,比写两个条件更简洁。

还有一个优化点:iaddq这条指令的存在可以显著减少 load-use 冒险。因为它不写条件码,也不产生需要等待的值,可以在很多原本要插nop的位置替代一条irmovq+addq的组合。这就是为什么后来的实验版本会引入这条指令。

5.5 控制冒险:猜错了就得付代价

条件跳转是流水线最讨厌的东西。取指阶段就要决定下一条 PC,但这时候jXX的条件还没算出来(要等到执行阶段)。怎么办?预测。

最简单的策略是"总是预测跳转"(predict taken),因为循环末尾的分支大多是成立的。代价是猜错时要把已经取进来的指令全部清掉,插入气泡,这叫做取消(misprediction),会把流水线填满好几个周期的nop,吞吐率立刻掉一截。

取消逻辑写起来是这样的:

bool mispredicted = (E_icode == IJXX && !e_Cnd) || # 预测跳但实际不跳 (D_icode in { IRET, IJXX } && ...); # 预测不跳但实际要跳

一旦检测到预测错误,W、M、E三个寄存器要清空(bubble),D要清空,F继续取指但 PC 要改成正确的目标地址。这一段的 HCL 非常容易写漏,建议把"取消时哪些信号置位"列成表,一个一个核对。

另外别忘了ret也是控制冒险:返回地址存在内存里,要读出来才知道往哪跳。所以ret必须暂停,等内存读完才能继续取指。这一点很多人第一次做的时候会漏,导致函数调用一多程序就跑飞。

5.6 异常:半路出事怎么收场

Y86-64 有三种异常:非法指令(INS)、访存越界(ADR)、halt(HLT)。流水线里异常的处理原则是:记录下来,等这条指令走到写回阶段再统一停下。

具体做法是在流水线寄存器里带一个Stat字段,每级往下传,遇到异常就置位,后面的指令不再更新状态。这样做的原因很简单:异常指令之前的指令必须完成,之后的指令必须撤销,而"之前的都完成了"这个时间点恰好是它到达W阶段的时候。

这个设计有个反直觉的地方:异常不是立刻生效的。一条mrmovq越界,它后面几条指令可能已经进入流水线甚至执行了一部分。但因为状态更新只发生在W阶段,这些"提前执行"的副作用不会落盘,所以最终结果是对的。理解这个"延迟提交"的思想,你就理解了后面乱序执行里重排序缓冲(ROB)的雏形。

6. 动手实操:把实验真正跑通的做法

6.1 环境准备里最容易忽略的两件事

工具链本身很简单:yas汇编器、yis指令模拟器、sim周期模拟器,再加一个hcl2c(把 HCL 翻译成 C 代码)。但有两件事新手常踩:

第一,每次改完 HCL 都要重新生成。make会自动调用hcl2c,但如果你手动改错了文件路径,make可能什么都没做却返回成功。养成改完立刻make并看输出的习惯。

第二,sim的-i参数和-t参数语义不同。-i只跑指令级模拟,速度快但看不到内部信号;-t会按周期打印,信息量大但输出很吵。调试阶段建议先用-i确认语义正确,再用-t定位 HCL 的问题。

make clean && make # 全量重建,避免增量编译的坑 ./yas test.ys # 汇编 ./yis test.yo # 语义验证 ./sim -t test.yo # 周期级追踪

6.2 测试用例要分层写

我吃过一次亏:写了一个大而全的测试程序,跑出来结果不对,但不知道错在哪一步。后来改成三层:

• 第一层:单条指令。每条指令一个.ys文件,跑完看寄存器值。
• 第二层:指令组合。比如irmovq+addq+rmmovq+mrmovq,验证数据在寄存器和内存之间来回搬。
• 第三层:控制流。写一个循环,写一个递归函数(验证call/ret/栈)。

这三层跑通,你的处理器基本就是对的。再往上是性能测试,比如统计一条循环的 CPI(每指令周期数),看流水线有没有白白浪费周期。

6.3 调试的关键是"对照两个世界"

最好的调试方法是同时跑yis和sim,用同样的输入,逐条对比。yis给出的是正确的语义结果,sim给出的是你的硬件实现的结果,一旦某条指令之后两者分叉,问题就定位在那条指令上。

具体操作:在.ys文件里每执行一条关键指令就插一个halt(或者用sim的交互模式),看寄存器快照。吐出来的十六进制值和预期不符,就往回找三个周期——因为流水线的效果会延迟显现,出错的地方往往比你看到的位置早两到三个周期。

6.4 几个高频错误的速查表

7. 我踩过的那几个坑

第一个坑是转发优先级。我一开始把d_rvalA放在选择块的最后当作默认值,结果 E 和 M 两条转发路径的判据同时成立时,行为完全随机。原因是 HCL 的选择块按顺序匹配,而我没有把最新的路径放在前面。改成e_valE优先、M_valE其次、W_valE再次、最后才是寄存器堆,问题立刻消失。这个教训是:转发本质上是一个"最新值优先"的仲裁问题,顺序错了逻辑就错了。

第二个坑是条件码的时序。在 SEQ 里,OPq写 CC 和后面的cmov读 CC 在同一个周期内完成,天然正确。但到了 PIPE,CC 在执行阶段末尾才更新,而cmov需要在执行阶段开始时就知道条件。这意味着如果cmov紧跟一条OPq,它会读到旧的CC。这个问题不好修,常见的偷懒做法是在这种情况下插入暂停,或者干脆让cmov读 E 阶段末尾的值。我当时的处理是加了一条判据让cmov在检测到紧邻的OPq时暂停一个周期,虽然损失了一点性能,但结果完全正确。

第三个坑是异常和 halt 的传播。halt指令走到写回阶段之后,整个模拟器应该停下来,但流线里可能还有几条指令在飞。我的第一版实现里,halt之后的指令还在继续改寄存器,结果状态码是HLT,但寄存器内容已经乱了。修法是把Stat一路传下去,在W阶段检查,一旦不是AOK就冻结所有状态更新。

第四个坑是**jXX的valC和valP混淆**。jXX指令长 9 字节,valC是 8 字节目标地址,valP = PC + 9。我在写 PC 更新的时候,把"条件不成立"的分支写成了valC,结果所有不跳的分支都跳到目标地址去了。这个 bug 在只有一个循环的程序里表现正常(因为循环总是跳),要写一个if-else才暴露出来。

第五个坑比较冤:irmovq的rA字段是0xF,但我把它当成 0 号寄存器读了。因为0xF在某些调试输出里显示成f,和寄存器编号混在一起看串了行。后来我养成了一个习惯:每次看到寄存器编号比较,先确认两边都不是RNONE。

8. 这一章真正想教的东西

抛开那些信号名和 HCL 语法,这一章的骨架其实是一个通用的工程方法:把一个复杂系统拆成"状态 + 组合逻辑",把串行的路径切开并插入寄存器来提高吞吐,再用仲裁、暂停、取消三种手段处理依赖。

这套方法不只用在处理器上。你在写一个高并发的数据管道时会遇到同样的三件事:阶段切分(流水线)、数据依赖(转发的翻版:缓存和旁路)、控制依赖(分支预测的翻版:乐观执行 + 回滚)。理解了 Y86-64 的流水线,再去看任何"分阶段并行处理"的系统,你会发现套路是通的。

如果让我给后来的人一句建议:别急着跳到流水线那一章。SEQ 版本把每条指令的六个阶段老老实实走一遍、每个信号都手工核对过、每个测试用例都跑通,这个基础扎实了,流水线那一堆转发和暂停的判断,你只需要关心"多了一个周期的时间差"这一件事;基础不扎实,你会同时面对"逻辑本来就不对"和"时序导致的不对"两个问题,调试难度是乘法的。

我自己最后的做法是把 SEQ 的 HCL 打印出来,每一条word和bool都用铅笔在旁边标注它对应的是数据通路图上的哪根线,全部标完之后再开始改流水线。那几张纸现在还在我的笔记本里,比任何笔记都值钱。