简介：南京大学ICS课程PA实验压缩包面向修读计算机系统类课程的学生，是涵盖Nemu模拟器、抽象机、nanos-lite教学内核与Navy-Apps应用集的完整实验资料，配套源码与操作说明书，适合课程设计或作业实操使用。包内共487个文件，约741KB，以c/h源码文件为主，辅以makefile/mk构建脚本、s汇编、cpp及md说明文档，层级分明，便于对照Nemu、Makefile、init.sh等模块逐项调试。已有560人浏览学习。通过该资源可掌握CPU指令集、内存管理、Makefile工程组织、系统启动流程等核心知识，借助源码、构建脚本与README快速上手，理解高级语言到机器指令的转化及轻量内核的运行机制，是巩固计算机系统底层原理的高效练习素材。
1. 先搞清楚这是什么：ICS 的 PA 实验到底让你做什么
拿到这份 ICS 课程 PA 实验部分（内含源码和说明书）的压缩包，我第一个动作不是解压，而是想清楚它到底是什么。PA 全称是 Programming Assignment，它和普通作业完全不一样——普通作业让你调用现成的库写出功能，PA 是让你在框架代码上“造”一台能跑程序的模拟计算机，从取指、译码到指令执行全都要由你补齐。
听起来像高级课题，但 PA 的设计恰好相反：源码只是骨架，说明书才是施工图。压缩包里每个阶段的 TODO 注释都对应计算机的某个部件，每个阶段的验收命令则告诉你“做到什么程度算过关”。所以这个实验包的正确打开方式不是先读代码，而是先读说明书。
这篇笔记要解决的就是拿到这个包之后最实际的问题：先看什么、环境怎么搭、第一个阶段怎么跑通、哪些位置最容易翻车，以及最后怎么验证自己真的做对了。适合正在学计算机系统导论、准备系统方向面试，或者想补底层基础的自学者。
2. 解压与说明书速读：先看懂实验包内部结构再动手
这类 PA 实验包解压后，目录里通常铺着 src、include、test、doc 等看起来“都跟代码有关”的目录。很多人条件反射地双击源码文件开始读，但我会先做另一件事：把说明书找出来通读一遍。这不是形式主义，而是因为 PA 的工作方式不是“理解全部源码再动手”，而是“按阶段在已知骨架上补零件”。如果不知道每个零件的位置和验收标准，读源码等于读一本没有目录的书。
2.1 先读说明书还是先看源码？我的答案永远是先说明书
PA 包里的源码和说明书，可以理解成“半成品数据”和“操作手册”的关系。源码里已经有完整的框架，缺的是若干关键函数；说明书则告诉你每个阶段要补哪个函数、补完之后用什么命令验证。两者的优先级在这个实验里非常明确：说明书在前，源码在后。
我一般会从说明书里先提取三样东西。第一是阶段划分：PA 通常被拆成 PA0、PA1、PA2 这样的检查点，每个阶段结尾都有一组验收命令，输出 PASS 才算过关。第二是快速开始命令：说明书靠前的“环境准备”或“快速开始”段落，几乎一定会给出 make 和 make run 这两条命令，先在终端跑一遍，确认框架能编译、能启动。第三是文件权限边界：哪些目录属于“允许修改区”，哪些属于“公共区/只读区”。实验包通常会在说明书里明确“不要修改头文件和 Makefile”，这条红线一旦踩了，即使代码逻辑正确，验证脚本也可能直接判不通过。
很多同学的第一个翻车点就在这儿：不读说明书，直接改了一个看起来“很碍眼”的公共头文件，结果后面重新 make 时冒出一堆编译错误，最后只能把整个包重新解压重来。这不是技术能力问题，是流程顺序问题。所以我的习惯是：解压后先花 20 分钟读说明书，把验收命令和目录边界记下来，再碰代码。
如果说明书在压缩包里容易被漏掉，我还会检查根目录有没有 README 或 doc 目录；说明书是 Markdown 就直接打开，是 PDF 就先看目录页和“实验阶段”章节，然后把每个阶段的“目标”和“验收命令”位置标出来。这一步做完，整个实验的工作量和工作顺序就已经很清楚了。
2.2 用 tree 和 grep 五分钟建立目录地图
说明书读完，接下来才轮到源码目录。我习惯先跑两条命令做一张“地图”，而不是用文件管理器一层层点开。
$ unzip -q PA_ICS.zip -d PA_ICS $ cd PA_ICS $ tree -L 3 -d这里unzip -q的-q是静默模式，避免解压时成百上千个文件列表刷屏；-d PA_ICS把内容解压到指定目录。tree -L 3限制只显示三层目录，-d表示只列目录不列文件。如果你的系统没有 tree，可以用find . -maxdepth 3 -type d替代。这条命令的输出会告诉你整个实验包的骨架：比如根目录下有 src/、include/、test/、tools/、doc/ 这样的常见划分，src 里再分 cpu/、memory/ 之类的模块。
$ grep -rn "TODO\|FIXME\|XXX" src include --include="*.c" --include="*.h"grep 的-r是递归搜索，-n显示行号，--include限定只扫 C 源文件和头文件。PA 框架的惯用做法是在待补全的位置写下 TODO 注释，比如“TODO: 实现取指操作，返回当前 PC 所在的 32 位指令”。这条命令执行后，你会得到一张带行号的“施工清单”，每个 TODO 就是某个阶段要填的坑。把这些行号记下来，后续改动基本都围绕它们展开。
我还会顺手执行du -sh */看一下各目录的体积。哪个体积最大，通常是测试用例或参考实现；最小的 src 目录，往往才是你真正要动的地方。体积对比本身就是一种信息：如果 test 目录占了压倒性比重，说明验收主要靠跑测试用例，而不是靠人工检查代码。
2.3 从 Makefile 反推实验入口与调试方式
目录地图有了，下一步是看 Makefile。PA 的 Makefile 不仅是编译脚本，它还是整个项目的“操作面板”——所有你平时要反复执行的命令，几乎都映射在这里。
$ grep -nE "^(run|debug|test|all|clean):" Makefilegrep 的-E开启正则匹配，^(run|debug|test|all|clean):匹配这些 target 所在的行。输出会告诉你框架预设了哪些命令入口，常见的有三种：run:启动模拟器；debug:拉起 gdb；test:跑回归测试脚本。其中test往往是你最重要的“验收命令”，阶段完成的标准就是make test全部 PASS。
$ grep -nE "^(CC|CFLAGS|LDFLAGS)" Makefile这一组变量决定编译方式。CC=这一行最关键：如果它指向riscv64-unknown-elf-gcc这类交叉编译器，说明模拟器的目标机是 RISC-V；如果只是gcc，目标机大概率是 x86。这个信息决定你该装什么工具链，也决定你用哪个 gdb 调试——交叉目标一般需要支持多架构的 gdb。CFLAGS 里的优化选项也值得留意：如果在调试阶段发现“代码执行顺序和源码对不上”，很可能是-O2这类优化在捣乱，开发期临时改成-O0能省很多事。
看 Makefile 还能规避一个隐蔽的坑：有些测试脚本会硬编码编译输出的路径，比如直接执行./build/pa-test。如果你为了“保持整洁”改了输出目录，测试脚本未必跟着改，结果就是代码好像没问题，但make test全红。所以拿到 Makefile 后，不要轻易改目录和 target 名，只改源码就够了。这是我见过最多人吃亏的细节。
注意：实验包自带的 Makefile 在多数情况下属于“只读区”，不要为了一时的编译方便改动它的核心路径，否则验收阶段可能无法复现你的结果。
2.4 第一次编译：在动手前确认框架本身是健康的
读完说明书、画完目录地图，接下来建议别急着改代码，先编译一遍，确认这个包在干净状态下是能跑的。PA 框架自带基础功能，只是待补全的地方被注释或者返回了占位值；正常情况下它应该能编译通过、能启动、甚至能加载一个空程序。
$ make clean && make $ make runmake clean先清掉历史编译产物，避免旧的 .o 文件干扰本次构建；后面直接make执行 Makefile 的默认 target。make run启动模拟器，如果一切正常，你会看到交互提示符。这一步的意义在于：它把“环境问题”和“代码问题”分开——如果没改任何代码就编译失败，那是环境或压缩包本身的问题，和后面写代码无关，必须先把环境修好再进入任务。
编译时我还会顺手记一下有哪些 warning。框架自带的代码可能有意留一些 warning（比如“TODO 未实现”），这没关系，因为你本来就要去实现它们；但如果 warning 出现在公共头文件或编译选项上，多半是环境不匹配，最好在动手前解决掉，否则会在调试阶段反复干扰判断。这一步做完，你的“施工起点”才算是真正确认下来。
3. 搭好运行环境：没有这些工具链，PA 连编译都过不去
PA 实验包解压之后，最容易卡住的一步其实不是写代码，而是环境配置。平时写 C 程序直接用系统自带的 gcc 就够了，但在 PA 里，这套编译器很可能不适用——因为你的电脑和 PA 模拟器要运行的“目标程序”不是同一种架构。这一章先把为什么和怎么办讲清楚。
3.1 为什么 PA 需要交叉工具链而不是系统 gcc
一句话解释：你电脑上的 gcc 默认生成的是 x86_64 机器码，而 PA 模拟器内部按目标机指令集（常见的是 RISC-V）解码执行。如果用系统 gcc 编译一个客户程序丢给模拟器，模拟器会把 x86_64 的二进制当 RISC-V 指令解析，结果必然是“不认识的 opcode”，表现为一开机就 panic 或者乱执行。
交叉编译器的名字本身就说明问题：riscv64-unknown-elf-gcc里，riscv64是目标 CPU 架构，unknown表示厂商字段无关紧要，elf表示输出 ELF 格式的目标文件。它和系统 gcc 的差别不是版本差异，而是产出的机器码“说哪种语言”。交叉编译器在宿主机器上运行，但生成的是目标机指令；PA 场景里，模拟器负责模拟 CPU 执行这些目标机指令，客户程序就是模拟器的试验对象。
也有少数 PA 实验把目标机定为 x86，这时确实可以使用系统 gcc，但要注意三个约束：一是按指导书要求加上-m32或指定-march；二是关掉你理解不了的优化，避免编译器把指令重排成难以对照源码的形态；三是确认模拟器是否只接受静态链接的 ELF。如果客户程序依赖动态链接库，模拟器不会去加载系统里的 .so，运行时大概率直接失败。这些细节在说明书的环境章节一般有提醒，没有的话就按最保守的方式配：静态、不加优化、明确指定架构。
3.2 最小依赖清单与安装命令
以 RISC-V 目标机的常见 PA 为例，我在动手前的依赖清单大致是这张表：
| 依赖名称 | 用途 | 怎么验证装对了 |
|---|---|---|
| build-essential | 提供系统 gcc、make 等基础工具 | gcc --version |
| riscv64-unknown-elf-gcc | 把客户程序编译成 RISC-V ELF | riscv64-unknown-elf-gcc --version |
| gdb-multiarch | 调试运行在模拟器里的客户程序 | gdb-multiarch --version |
| lib32gcc / gcc-multilib | 目标机为 x86 且要求 32 位时使用 | 能编译一个-m32测试程序 |
| python3 + pyelftools | 解析 ELF、生成测试输入等辅助工作 | python3 -c "import elftools" |
注意 gdb-multiarch 和普通 gdb 的区别：普通 gdb 只能调试本机架构的程序；模拟器里的客户程序是 RISC-V 指令，需要支持多架构的 gdb-multiarch 才能正确解析寄存器、指令和内存。如果只用普通 gdb 连上去，最常见的情况是寄存器列表是空的或者全是错误值，非常误导。
安装命令在 Debian/Ubuntu 系通常是这样：
sudo apt-get update sudo apt-get install -y build-essential make gdb-multiarch \ binutils-multiarch lib32gcc-12-dev python3-pip pip3 install --user pyelftools参数说明：build-essential包含 gcc 和 make；gdb-multiarch和binutils-multiarch提供多架构的调试与二进制工具；lib32gcc-12-dev里的 12 是 gcc 主版本号，不同发行版不一定一样，装之前先执行gcc --version看一下再改数字。pyelftools是 Python 的 ELF 解析库，实验包的辅助脚本可能会用到，装到用户目录即可，不需要 sudo。
如果你的发行版搜索不到某个包，先用apt-cache search riscv看看仓库里有没有同类替代名，比如crossbuild-essential-riscv64也可以。包名在不同发行版之间差异很大，网上的安装命令并不能保证原样跑通，重要的是装完后用 3.3 的小测试验证，而不是看安装过程有没有报错。
3.3 用最小程序验证工具链真的可用
装完工具链不等于环境就绪，还要验证“交叉编译器是否真的产出目标机指令”。我会用最小的程序做测试：
$ cat > hello.c <<'EOF' int main() { return 0; } EOF $ riscv64-unknown-elf-gcc -o hello hello.c $ file helloriscv64-unknown-elf-gcc指定使用交叉编译器，而不是系统 gcc；-o hello指定输出文件名；file hello会打印 ELF 文件的架构信息。正常情况应该包含 RISC-V 字样，比如ELF 64-bit LSB executable, UCB RISC-V。如果输出显示x86-64，说明实际调用的是系统 gcc，编译器路径有问题，后面所有工作都会跑偏。
还可以用 readelf 再确认一次：
$ riscv64-unknown-elf-readelf -h hello | grep Machine $ readelf -h hello | grep Machinereadelf 的-h打印 ELF 文件头，grep Machine过滤出机器类型行。交叉版 readelf 和系统 readelf 都能读 ELF 头，因为 ELF 文件头本身是标准格式，所以两条命令的结果应该一致。如果 Machine 字段显示 RISC-V，说明这个文件确实是模拟器能认的目标机程序。这一步验证比安装过程本身更重要——它确认的是“编译器链路是否通顺”，后面模拟器加载客户程序出问题时，可以先回到这里。
验证完交叉编译器，我还会顺手跑一下模拟器的空转。make run启动模拟器后，哪怕界面只有一个提示符，也说明框架自带的启动流程是通的。这相当于把 PA 的“最小环境路径”走通了。如果模拟器在启动阶段就报错，先别急着写代码，把启动流程的日志选项打开，看它在加载什么、卡在哪一步。启动失败通常集中在 ELF 加载路径不对、内存初始化大小不对这两个原因上，这两类属于环境边界问题，和你的逻辑代码无关。
4. 按说明书跑通第一个 PA 阶段：从监控器到第一条指令
前面几章把包的结构和运行环境讲清楚了，从这一章开始真正进入模拟器实现。我建议的做法是：不要按顺序从头到尾读源码，而是先找到那条“最小可运行路径”——从编译、启动到单步执行一条指令，先让模拟器“动起来”，再谈补全指令集。
4.1 PA 阶段推进的典型节奏：不要一口气写完再调试
PA 常见的阶段划分里，PA0 通常是环境配置和框架编译验证，PA1 开始进入模拟器实现：先让模拟器能取到指令，再逐条执行。不同课程具体分法会有出入，但推进节奏是一致的——每个阶段结束有一个检查点，验证手段是跑一组预置测试用例，而不是人工阅读代码。
我对每个阶段的建议都是同一句话：小步走，每补一个函数就跑一次回归。不要觉得“多写一点再一起调试”效率高。在模拟器这种状态机里，一次引入几十个错误再排查的难度远高于逐条推进。模拟器本质是一个以 PC 为指针的状态机，任何一步出错，后续所有状态都会跟着错，而错误现象往往是“寄存器全是异常值”“程序陷入死循环”“莫名其妙跳到错误地址”，这些现象定位起来非常消耗时间。
具体怎么小步走？从最小可运行子集开始。比如先只实现一条加法指令，让它能跑完一个只有一条指令的客户程序，然后把指令种类逐条扩展。每增加一种指令，跑一次对应测试。这样做的好处是：当测试失败时，你几乎可以确定问题出在刚改的那几条指令里，而不是全工程范围内。我见过太多同学“一口气写两百行然后连续调三天”的情况，最后大多回到“删掉重来”的老路，返工代价远高于一开始的慢。
4.2 最小复现路径：编译、启动、单步看寄存器
PA 阶段开始前，先确认三条命令能跑通：编译、启动、单步。
$ make clean && make $ make runmake clean删除旧中间产物，&&保证前一条成功才执行后一条；make构建目标。make run启动模拟器。如果框架自带交互界面，启动后通常会等在一个提示符前。这一步只要进入提示符，就说明你的“能跑”状态已经达成。
进入模拟器后，第一件事不是跑完整测试，而是用单步命令走一条指令。模拟器的交互界面通常提供类似si和info reg的调试命令，具体名字以说明书为准：
模拟器 > si 模拟器 > info regsi执行一条客户程序指令然后停下来；info reg打印当前所有寄存器值。这时你要对比说明书里给出的“第一条指令执行后的期望状态”，比如 PC 是否从初始地址前进到下一个合法地址，某个寄存器是否变成了期望值。如果 PC 没动或寄存器值是随机的，说明取指或 pc 更新逻辑有问题，这是后续一切错误的总源头。
启动时我还会立刻看一下 PC 的初始值。RISC-V 客户程序的常见入口地址在0x80000000附近，模拟器从这个地址开始取指。如果 PC 初始值是 0 或其他奇怪的值，问题一般在内存加载逻辑，而不是执行逻辑。把这个初始状态和说明书给出的值对照，能省下很多无头绪的调试时间。
4.3 改一处代码让它真正“跑起来”：以指令分派为例
PA1 最核心的代码改动通常集中在“指令分派”这个位置：从内存中取出一条 32 位指令，解析出 opcode，然后交给对应的执行函数。不同实验包的接口名不一样，但通用骨架大致长这样：
// 模拟器主循环：取指、译码、执行 void cpu_exec_once() { uint32_t pc = cpu.pc; uint32_t inst = guest_read(pc, 4); // 从客户地址空间读 4 字节指令 uint32_t opcode = inst & 0x7f; // RISC-V 指令的低 7 位是 opcode switch (opcode) { case 0x33: exec_r_type(inst); break; // 寄存器-寄存器运算类指令 case 0x03: exec_load(inst); break; // 内存加载类指令 case 0x63: exec_branch(inst); break; // 条件分支类指令 default: abort_with_message("unsupported opcode: 0x%02x at pc=0x%x", opcode, pc); } }代码里的guest_read负责从模拟器的客户内存中读数据，参数pc是程序计数器地址，4表示读 4 字节，因为 RISC-V 指令在大部分实验中是定长 32 位。inst & 0x7f取出指令最低 7 位——这是 RISC-V 指令的通用编码规则。switch 分派把不同类型的指令送去对应的执行函数，abort_with_message则用于兜底：遇到不认识的编码立即停下报错，而不是带着错误状态继续跑。
这里有一个必须遵守的细节：每个 exec 函数执行完指令之后，必须更新 cpu.pc。如果某个 exec 函数忘记改 pc，主循环里的取指会一直在原地拿到同一条指令，表现就是“模拟器在跑但 PC 不动”。我通常会在主循环里加一个断言：
uint32_t old_pc = cpu.pc; cpu_exec_once(); assert(cpu.pc != old_pc); // 每条普通指令执行后 PC 必须前进这个断言在每次执行后检查 PC 是否变化，如果普通指令执行完 PC 还是原值，立刻中断。它能把“静默死循环”问题变成一句明确的报错。代码里old_pc保存执行前的 PC，执行结束后与当前 PC 对比，两步都写在主循环周围，不影响其他模块。
改完这段之后，马上回到 4.2 的复现路径：重新 make，用si单步执行一条指令，看 PC 和寄存器的变化是否符合预期。如果通过，再考虑扩展下一条指令。这个“改一执行一验证一”的循环，是整个 PA 实验里性价比最高的推进方式。
5. 避坑：PA 实验最典型的 5 个翻车现场与排查方法
PA 实验的 bug 大多不复杂，但很会“藏”。下面这 5 个坑是我在类似实验包里见得最多、也最耗时的类型，每一条都按“现象、原因、解决”的顺序说清楚。
5.1 坑一：make 报错“找不到头文件”
现象：执行 make 时，编译阶段报fatal error: xxx.h: No such file or directory，而且报错的头文件在目录里明明存在。
原因：绝大多数不是文件不存在，而是编译器的头文件搜索路径与实验包的预期不一致。交叉编译器的默认头文件路径指向自己的目录，而系统 gcc 的头文件路径指向/usr/include；如果 Makefile 写的是相对路径-Iinclude，而当前工作目录不对，也会出现同样报错。另外，如果实验要求 32 位目标机而你没装 multilib 支持，系统缺少 32 位版本的公共头文件，也会报类似错误。
解决：先运行make V=1（如果项目不支持，就临时在 CFLAGS 里加-v）查看编译器的完整搜索路径。确认-I参数是否正确指向实验包根目录下的 include 目录；确认交叉编译器执行--print-sysroot能输出正确的系统根路径。多数情况下，把头文件路径写对、装好 multilib 包，问题就消失了。这种问题要尽早处理，否则你的所有后续工作都会停在编译阶段。
5.2 坑二：程序跑起来但 PC 值始终不动
现象：模拟器启动后能执行，但每次单步观察，CPU 的 PC 都是同一个值；或者 PC 虽然变了，但永远在一个很小的循环里打转，跑不到下一个有效地址。
原因：最常见的两个原因，一是某个 exec 函数没有更新 cpu.pc，执行完一条指令后 PC 没变，主循环于是反复取同一条指令；二是指令执行函数把 pc 更新写在了错误的位置，比如在译码阶段就改 pc，导致分支指令的“目标地址”和“顺序递增地址”混在一起，实际效果是反复跳回同一个点。
解决：按 4.3 的方式在主循环里加 PC 断言，先确认到底是“没更新”还是“更新值不对”。如果是没更新，在 exec 函数末尾统一写cpu.pc += 4；如果已经更新但总是回跳，把分支指令的目标地址计算过程单独打印出来，对照指导书的编码规则逐字段检查 immediate 扩展是否正确。PC 问题是模拟器里最容易被忽视的“故障放大器”：PC 错一步，后面所有寄存器和内存访问全错，但表象却五花八门。
5.3 坑三：结构体直接映射指令导致的对齐错位
现象：把指令编码定义成结构体，然后用*(inst_t *)buf从内存直接读指令，读出来的 opcode 和操作数字段全是乱的，某些字段值看起来像随机数。
原因：C 语言结构体存在对齐和填充规则，编译器可能会在字段之间插入 padding，导致字段的内存偏移和指令编码的位域位置不一致。更麻烦的是，即使加了__attribute__((packed))，字段对齐了，但位域（bit-field）在不同编译器版本上的分配方向并不完全可移植，读出来的值仍可能和 RISC-V 编码规则对不上。
解决：不要用结构体映射指令，改用纯位运算手工提取字段。比如 RISC-V 的 I 型指令 immediate 需要把第 20 到第 31 位拼出来：先(inst >> 20) & 0xfff得到低位部分，再用(inst >> 31) & 1判断符号位，最后手动做符号扩展。虽然位运算代码看起来不如结构体优雅，但它直接对应手册里的编码规则，排错时一眼就能看出问题在哪一位。用位运算处理指令编码，是这一阶段正确性与效率最好的平衡点。
5.4 坑四：寄存器堆出现 0xDEADBEEF 之类的异常值
现象：模拟器运行一段客户程序后，某几个寄存器的值变成了 0xDEADBEEF、0xCAFEBABE 这类标志性数值，或者每次运行结果都不一样。
原因：寄存器堆在实现上通常是一个数组，比如uint32_t regs[32]。如果启动时没有把数组清零，数组里残留的是上一次运行的数据或未初始化数据；而测试用例往往只检查“被写过的寄存器”，没被写过的寄存器如果带着旧值，就可能被带入后续计算。另一个常见原因是越界访问——比如寄存器编号为 32 时写进了regs[32]，越过数组末尾，破坏了相邻内存区域。
解决：在 CPU 初始化函数里用memset(regs, 0, sizeof(regs))清零整个寄存器堆；同时在使用寄存器编号前加范围检查，如assert(idx >= 0 && idx < 32)。如果问题仍然随机出现，用 AddressSanitizer 重新编译模拟器，即在 CFLAGS 里加-fsanitize=address -g，运行测试后工具会直接指出越界位置。ASan 在模拟器这类数组密集的代码里非常有效，能帮人省下一整晚的抓瞎时间。
5.5 坑五：现象不稳定，同一段代码有时过有时挂
现象：make test 连跑两次，一次全过，一次挂在某个用例上；或者只跑某个测试文件时正常，整套一起跑时结果全乱。
原因：这类“偶发失败”在模拟器里几乎都指向未初始化状态。常见的有三种：一是全局变量没有在重置逻辑里清零，第二次运行时仍带着第一次的残留；二是在多阶段实验里，客户程序之间共享了内存，上一个程序留下的数据污染了下一个程序的初始状态；三是随机数或时间相关的辅助函数影响了执行路径，导致状态不可复现。
解决：给模拟器加一个reset()函数，把所有 CPU 状态、内存、设备状态统一恢复初始值；每次启动模拟器时强制调用它，而不是只做一次初始化。同时把“每次运行前打印一条初始状态日志”作为习惯，日志里包含 PC、栈指针、寄存器堆前几个值，这样复现问题时能快速对比两次运行的初始状态是否一致。偶发 bug 一旦能稳定复现，就离修好不远了。
6. 验证与进阶：怎么证明你的 PA 真的做对了
6.1 用 diff 回归锁定行为
每个阶段结束时，我会先把当前实现保存为一个基线版本，然后跑一遍完整测试并把输出落盘：
$ make test 2>&1 | tee test_BASE.log $ git diff > change.diff2>&1把标准错误合并到标准输出，tee test_BASE.log把结果同时显示并写入文件。之后再改动，跑同样的命令得到新日志，和基线做 diff。这个习惯能让你在“改崩了”的时候一键回到上次正确的状态，相当于给自己留了后悔药。
6.2 加一个指令计数 Trace，防止死循环
模拟器最容易卡住的 bug 是无穷循环：PC 在一个局部不停打转，程序看起来在跑，但永远不结束。给主循环加一个指令计数器，是成本最低的保护手段：
static uint64_t inst_count = 0; while (true) { inst_count++; if (inst_count > 50000000) { abort_with_message("inst_count exceeded, likely infinite loop"); } cpu_exec_once(); }inst_count是全局计数器，每次主循环加一；超过上限就中止。上限值要根据测试用例的大小调整：跑大型基准测试时放宽，调小程序时收紧，保证该死循环时尽快被拦住。这个计数器还会带来一个额外收益：它本身就是最简单的性能指标，让你能大致感知每阶段实现的执行速度。
6.3 值得继续投入的两个方向
PA 实验跑通验收之后，还能往深走两条线。一是性能：在模拟器里统计每条指令的执行频率，找出热点指令——这比直接上 profiler 更能帮你理解真实 CPU 设计为什么会对某些指令做特殊优化。二是功能扩展：对照目标架构手册，把模拟器还没支持的指令逐条补全，然后用更大规模的测试集做回归。这两件事都不需要改动实验包的整体结构，却能在系统层面把“模拟器”变成“你真正吃透了的一台 CPU”。
我的习惯是每完成一个阶段就打一个版本标签，哪怕只是改了一行 PC 更新逻辑。回头看去，PA 实验真正教给我的不是“写模拟器”，而是如何在不理解全部细节的前提下，用说明书、断言、日志和最小用例，把一个黑匣子逐步变成白盒子。希望帮到你。
本文还有配套的精品资源，点击获取
