从sdb到CPU模拟：NEMU取指-译码-执行与内存访问基础设施

简介：围绕NEMU PA1的概述、原理与应用展开的简明技术文档，面向计算机系统课程学习者、体系结构方向研究者以及从事操作系统与嵌入式底层开发的工程师，帮助读者理解NEMU模拟器的基础设施与简单调试器sdb的实现思路。全文从项目定位入手，依次梳理CPU模拟、内存模拟、设备模拟与调试器实现等关键环节，并对单步执行、断点设置、寄存器和内存查看、表达式求值等功能背后的机制作出说明，同时延伸到计算机系统教学、体系结构验证、底层软件测试等应用场景。资源包仅含1个PDF文件，大小约74KB，篇幅紧凑，适合作为课程实验前的概念梳理或项目开发中的速查材料。目前已有799人学习，说明其在NEMU相关学习中具有一定参考价值。读者可借此快速建立PA1的整体框架，理解模拟器如何解析指令、维护CPU状态并读写内存，也能把握调试器在客户程序监控与控制中的作用，为后续实验实现和问题排查提供思路。

1. 从一条命令说起：为什么模拟器要先长出一个调试器

很多人第一次翻开 NEMU PA1 的任务清单会犯嘀咕：要学的明明是 CPU 怎么执行指令，第一步却是先造一个调试器 sdb？顺序看着是反的——调试器本该是拿来调试别人程序的工具，怎么反倒成了被实现的对象。真相是，NEMU 这种用软件模拟硬件的程序天生是个黑匣子：客户程序跑在里面，指令一条条执行，寄存器一位位变化，外部完全看不见。没有 sdb，你连「刚才那条指令到底改了哪个寄存器」都只能靠猜。PA1 把调试器放在最前面，不是教你用调试器，而是让你先给这台机器装一副仪表盘；装表的过程本身，就逼你把寄存器怎么存、内存怎么寻址、指令怎么取这几件事想明白。这些正是 NEMU 基础设施的地基。

2. 取指-译码-执行：NEMU 的 CPU 模拟到底在循环什么

2.1 一个 while 循环撑起的执行引擎

抛开所有命令行外壳，NEMU 的心脏只有一个循环：不断从内存里取一条指令，弄清楚它要干什么，把它要干的事干完，然后让 pc 指向下一条。这个结构在教科书上叫「取指-译码-执行」，在 NEMU 里对应execute()里的一个 for。

/* 跑 n 条指令，n 为 -1 时相当于一直跑 */ static void execute(uint64_t n) { for (; n > 0; n --) { exec_once(&cpu, cpu.pc); /* 取指 + 译码 + 执行，顺带推进 pc */ if (nemu_state.state == NEMU_STOP) break; /* 命中断点，交出控制权 */ if (nemu_state.state == NEMU_END || nemu_state.state == NEMU_ABORT) break; } }

exec_once负责把单条指令的完整生命周期走完，它的实现刻意做得极短：

static void exec_once(CPU_state *s, vaddr_t pc) { s->pc = pc; /* 记录本条指令的起始地址，供断点、日志使用 */ isa_exec_once(s); /* 与 ISA 无关的外壳，真正干活的是它 */ cpu.pc = s->pc; /* 若指令本身没改写 pc，这里保证至少前进了一个指令长度 */ }

这里的s是一份 CPU 状态的临时副本，isa_exec_once在里面跑完之后再同步回cpu。多做一次赋值不是为了好看，而是为了让「这条指令执行前的 pc」有地方存放——日志、断点判定、出错回溯都靠它。nemu_state是个状态机，NEMU_RUNNING表示正常跑，NEMU_STOP表示被某个条件（断点、单步额度耗尽）主动停下，NEMU_END表示客户程序以正常方式结束，NEMU_ABORT表示撞上了无法继续的错误。sdb 的si、c两个命令本质上就是给execute传不同的 n：si 5传 5，c传 -1。

提示：n是uint64_t而c传 -1，靠的是补码回绕成一个极大的正数，循环自然近似无限。这是老练写法，但读代码时容易被n > 0迷惑。

2.2 寄存器与 pc：CPU 状态的最小集合

CPU 状态用一个结构体表示，PA1 阶段它小得可怜：一组通用寄存器加一个 pc。x86 是 8 个通用寄存器加 eflags，riscv32 是 32 个通用寄存器，具体数量由配置宏决定。

typedef struct { word_t gpr[MUXDEF(CONFIG_RV_REGNUM, 32, 8)]; /* 通用寄存器堆 */ vaddr_t pc; /* 程序计数器 */ /* x86 配置下还会有 eflags、cs 等段寄存器 */ } CPU_state;

word_t、vaddr_t这类 typedef 是 NEMU 里非常关键的一层抽象。它们被统一定义为 32 位无符号整数（uint32_t），然后 ISA 相关的代码一律用这些别名，而不是直接写int。好处是换 ISA、换位宽时只改一处；代价是所有算术默认是无符号回绕的，这一点在第 5 章会变成一个真实的坑。

sdb 的info r命令就是把这个结构体翻译成人能读的东西：拿一个「寄存器编号 → 名字」的映射表，按顺序打印gpr[i]，再单独打印pc。看起来只是几行 printf，但它迫使你想清楚一件事：寄存器名到编号的映射是 sdb 层的字符串问题，编号到值的映射是 CPU 层的数组下标问题，这两层不能混。混了就会写出gpr["eax"]这种念头，而这在 C 里必然错。

2.3 译码：opcode_table 与 exec 函数指针

取指好理解，难的是译码。一条 32 位指令里塞了操作码、若干寄存器编号和立即数，怎么在一瞬间判断「这是 add 还是 jmp」？

常见做法是一张分发表。表的每一项保存一个位模式和掩码，用「指令字 AND 掩码 == 模式」来判断命中：

/* 每一项对应一种指令格式，exec 是它的执行函数 */ static const struct { int (*exec)(uint32_t); /* 执行体，返回执行结果或状态 */ uint32_t pattern; /* 特征位 */ uint32_t mask; /* 哪些位参与比较 */ } opcode_table[OPCODE_NUM] = { { add_rm32_r32, 0x01, 0xfc }, /* 举例：只比较高 6 位 */ /* ... */ }; /* 取指之后，线性扫描表，第一个命中的就是它 */ static int decode_exec(CPU_state *s) { uint32_t inst = s->inst.val; for (int i = 0; i < OPCODE_NUM; i ++) { if ((inst & opcode_table[i].mask) == opcode_table[i].pattern) { return opcode_table[i].exec(inst); } } return -1; /* 未知指令 */ }

真实实现里为了提速，会把同 opcode 的指令再按 modrm 的若干位二级分类，用一个多位 switch 或二维表索引，避免线性扫表。但机制是一样的：把「识别指令」这件事从代码逻辑里剥离出来，变成数据表。这样加一条新指令只需要加一行表项和一个 exec 函数，不动主循环。这种「表驱动 + 函数指针」的分发，就是 NEMU 基础设施里最值得学的一手。

注意 exec 函数的签名是int (*)(uint32_t)：只收指令字，不收 CPU 状态。这意味着每个 exec 函数必然要访问一个全局的cpu变量——这看着不优雅，但它让所有 exec 函数保持一致，便于批量注册。很多学习者在 PA1 时会想把状态一路传参下去，结果每加一条指令都要改函数指针类型，最后不得不回头。血泪经验是先按框架给的签名写，别自作主张。

3. 内存模拟：一个字节数组如何骗过客户程序

3.1 guest 地址到 host 地址：guest_to_host 的那一次减法

客户程序眼里的地址，和宿主机上那块内存的地址，完全是两回事。NEMU 用一个巨大的字节数组pmem充当客户机的物理内存，然后用一次减法把两套地址打通：

static uint8_t pmem[CONFIG_MSIZE] PG_ALIGN = {}; /* 客户机物理内存本体 */ static inline uint8_t *guest_to_host(paddr_t paddr) { return pmem + paddr - CONFIG_MBASE; /* 客户地址 -> 数组下标 */ } static inline paddr_t host_to_guest(uint8_t *haddr) { return haddr - pmem + CONFIG_MBASE; /* 反过来，日志里常用 */ }

CONFIG_MBASE是客户程序物理内存的起始地址，常见约定取0x80000000这类远离 0 的值，理由后面会讲。真正关键的是这个设计选择的含义：guest 地址空间是连续的，host 上的承载物是一个平坦数组。客户程序以为自己独占一块从CONFIG_MBASE开始、长度CONFIG_MSIZE的内存，实际上它只是数组里的一段偏移。只要没人越过数组边界，这种「欺骗」就是完全透明的。

为什么要让起始地址远离 0？因为 0 地址在 C 里语义特殊（空指针），如果客户机物理内存从 0 开始，一片未初始化的指针和一段合法内存就无法区分了。把基点抬高，任何误把整数当指针的 bug 都会在宿主机上立刻段错误，而不是悄悄写坏模拟器的数据。这是「让错误尽早暴露」的经典取舍。

3.2 取指也是访存：inst_fetch 与 vaddr_read 的一致性

一个容易被忽略的事实：取指本身就是一次内存读。NEMU 没有把inst_fetch特殊化，而是让它走和普通读取完全相同的路径：

static inline uint32_t inst_fetch(vaddr_t *pc, int len) { uint32_t inst = vaddr_read(*pc, len); /* 取指 = 从 pc 处读 len 字节 */ *pc += len; /* 指针参数写回，得到 snpc */ return inst; }

注意参数是vaddr_t *pc而不是值传递。函数里*pc += len这一句，就是「静态指令长度」这个概念落地的地方，取完之后pc自动指向下一条。调用方先用一个临时变量snpc接收，等指令真的执行完了、确认没有跳转，再把snpc提交给pc。这样即使中途出错，pc也不会被污染到一个「取指成功但执行失败」的中间态。设计上这就是一次极简的「先算后提交」。

而vaddr_read在 PA1 阶段几乎是个空壳，因为分页还没开，虚拟地址等于物理地址：

word_t vaddr_read(vaddr_t addr, int len) { return paddr_read(addr, len); /* 未开启分页时，vaddr 直接当 paddr 用 */ }

这一层壳现在看着多余，但它是为后面留的位置。等分页机制接进来，这里会变成一次页表走查，而所有调用方一行都不用改。基础设施的价值往往体现在它暂时还没做什么。

3.3 越界访问与设备：什么时候该停下来

paddr_read才是有判断的地方：

word_t paddr_read(paddr_t addr, int len) { if (likely(in_pmem(addr))) { /* 落在模拟内存区间内 */ return pmem_read(addr, len); } /* 不在这块内存里，那可能是映射到某个设备的寄存器 */ IFDEF(CONFIG_DEVICE, return mmio_read(addr, len)); out_of_bound(addr); /* 既不是内存也不是设备，报错 */ return 0; }

in_pmem判断的是addr - CONFIG_MBASE < CONFIG_MSIZE，用减法而不是addr >= MBASE && addr < MBASE + MSIZE，是为了在无符号运算下天然处理回绕，少写一个分支。这种小技巧在模拟器里随处可见，因为它位于最热路径上。

对 PA1 而言，设备模拟是可选项。不开设备时，任何越界访问都应该让模拟器明确报错并停下，而不是返回 0 假装成功。理由很实际：客户程序越界读，多半是它自己的 bug，你如果静默返回 0，这个 bug 会被带到很远的地方才爆发，届时调用栈已经完全看不出根因。在底层基础设施里，早崩永远比晚崩便宜。

注意：pmem_read内部要按len做分支（1/2/4 字节各走一条），不能用一次memcpy糊过去——宿主机可能是大端也可能是小端，长度对齐与否也要单独判断。

4. sdb 的核心：命令行循环与表达式求值

4.1 从 readline 到命令分发

sdb 的外壳是一个读一行、切词、查表、调处理函数的循环：

for (char *str; (str = rl_gets()) != NULL; ) { char *str_end = str + strlen(str); char *cmd = strtok(str, " "); /* 第一个词是命令名 */ if (cmd == NULL) continue; char *args = cmd + strlen(cmd) + 1; /* 命令名之后的部分，整体作为参数 */ if (args >= str_end) args = NULL; /* 没有参数 */ int i; for (i = 0; i < NR_CMD; i ++) { if (strcmp(cmd, cmd_table[i].name) == 0) { if (cmd_table[i].handler(args) < 0) return; /* 返回负值表示退出 */ break; } } if (i == NR_CMD) printf("Unknown command '%s'\n", cmd); }

rl_gets是对 readline 的薄封装：有 readline 就用它拿到行编辑和历史记录，没有就退化成fgets。这一层封装让 sdb 在有没有第三方库的环境里都能编译，是「可选依赖」的标准写法。

命令表本身是个数组，每项存名字和处理函数指针。分发时用strcmp线性比对，命令数量是个位数，没必要上哈希。加命令只需要往表里加一行，和译码表是同一个思路。这种一致性不是巧合——表驱动是模拟器里反复出现的模式，因为它把「有哪些」和「怎么做」彻底分开了。

值得单独说一句的是strtok的副作用：它会就地修改字符串，把分隔符换成\0。所以cmd拿到的是第一个词的起点，args必须用cmd + strlen(cmd) + 1重新算，而不能指望strtok(NULL, " ")再取一次——那样会把带空格的表达式拆成好几段。

4.2 表达式求值：先分词，再找主运算符

p 1+2*3要打出 7，这背后是一个完整的词法 + 语法两级处理。常见做法是把输入切成 token 数组，再用递归的方式「找主运算符」。

词法阶段把字符串变成{类型, 值}的序列：

typedef enum { TK_NOTYPE = 256, TK_NUM, TK_HEX, TK_REG, TK_EQ, TK_NE, TK_AND, TK_OR, TK_NEG, TK_DEREF, /* 单字符运算符直接用 ASCII 码当类型 */ } TokenType; static struct rule { const char *regex; /* 该 token 的匹配模式 */ int token_type; } rules[] = { {" +", TK_NOTYPE}, /* 空白，直接跳过 */ {"0[xX][0-9a-fA-F]+", TK_HEX}, /* 十六进制字面量 */ {"[0-9]+", TK_NUM}, /* 十进制字面量 */ {"\\$[a-zA-Z0-9]+", TK_REG}, /* 寄存器名，带 $ 前缀 */ {"==", TK_EQ}, {"!=", TK_NE}, {"&&", TK_AND}, {"\\|\\|", TK_OR}, {"\\+", '+'}, {"\\-", '-'}, {"\\*", '*'}, {"\\/", '/'}, {"\\(", '('}, {"\\)", ')'}, };

分词完成后进入求值。核心思路不是从左往右扫，而是在区间 [p, q] 里找一个「最后才该算」的运算符，把表达式一分为二，递归求两边：

word_t eval(int p, int q, bool *success) { if (p > q) { *success = false; return 0; } /* 空区间，语法错误 */ if (p == q) { /* 只剩一个 token */ if (tokens[p].type == TK_NUM || tokens[p].type == TK_HEX) return tokens[p].value; if (tokens[p].type == TK_REG) return isa_reg_str2val(tokens[p].str, success); /* $pc、$eax 之类 */ *success = false; return 0; } if (check_parentheses(p, q)) /* 整体被一对括号包住 */ return eval(p + 1, q - 1, success); int op = find_dominant_op(p, q); /* 优先级最低、位置最靠右 */ if (op < 0) { *success = false; return 0; } /* 前缀运算符只递归右边 */ if (tokens[op].type == TK_NEG) return -eval(op + 1, q, success); if (tokens[op].type == TK_DEREF) return vaddr_read(eval(op + 1, q, success), 4); word_t lhs = eval(p, op - 1, success); word_t rhs = eval(op + 1, q, success); switch (tokens[op].type) { case '+': return lhs + rhs; case '-': return lhs - rhs; case '*': return lhs * rhs; case '/': if (rhs == 0) { *success = false; return 0; } return lhs / rhs; case TK_EQ: return lhs == rhs; case TK_NE: return lhs != rhs; case TK_AND: return lhs && rhs; case TK_OR: return lhs || rhs; } }

find_dominant_op里最重要的两条规则：优先级最低的优先当主运算符；同优先级时取最靠右的那个。后一条直接决定了左结合性——1-2-3如果把第一个减号当主运算符，会算成1-(2-3)=2；取最靠右的减号，才是(1-2)-3=-4。这个细节是 PA1 里翻车率最高的地方之一，原因很简单：从左往右扫代码写起来更顺手。

解引用*单独处理，是因为它是一元前缀，和乘号长得一样但优先级最高。判断依据是：这个*左边如果什么都没有，或者左边是运算符或左括号，那它就是解引用。而解引用必须走vaddr_read而不能直接对指针取值——它是一个客户机地址，不是宿主机地址。

4.3 单步、断点与继续：三种时间控制的语义差别

sdb的三个执行类命令，本质是对同一个execute循环施加三种不同的终止条件。

si [N]最直白：跑 N 条（默认 1 条）就停，N 直接传给execute。它控制的是指令数量。

c是跑到底或跑到下一个断点，传 -1 进去。它控制的是正常终止。

b只负责登记地址，真正的判定发生在execute循环的每一轮里：每条指令执行之前比一下cpu.pc和断点表，命中就把nemu_state.state设成NEMU_STOP，循环下一轮开头就 break 了。

这里有个微妙的顺序问题：比较 pc 是在exec_once之前还是之后？在之前比，命中的是「即将执行的那条」，符合直觉；在之后比，命中的是「刚执行完的那条」，会让你觉得断点永远晚一拍。

而c恢复运行时，还得多做一件事：如果当前 pc 正好在一个断点上，必须跨过它一次，否则一c就立刻又命中，形成死循环。常见实现是记一个「本次继续要跳过的地址」，第一次比对该地址时忽略。这类「后悔药」机制在调试器里非常普遍，因为调试器的状态和客户程序的状态天然是两套时间线。

5. 常见问题与排查：那些让 sdb 假装正常工作的坑

5.1 命令解析：表达式里的空格被吃掉了

现象：p 1 + 2能出 3，但x 4 0x80000000有时正常有时输出一堆 0；p -1直接报Unknown command或参数错误。

原因：有两种。一是用strtok把参数按空格切碎之后，只把第一段传给了 handler，剩下的丢了；二是参数串的起点用cmd + strlen(cmd) + 1计算时，如果命令和参数之间没有空格，这个指针直接越过了字符串结尾，读到的是\0后面的垃圾。表达式里带空格本身不是问题，问题在于分发层不应该假设「参数没有空格」。

解决：分发层只负责切出命令名，命令名之后到行尾的整段原样交给 handler，空格的处理全部下放给表达式分词器。分词器里把空白定义成一个TK_NOTYPE的 token 然后跳过，这样1 + 2和1+2走同一条路径。另外在算args之前必须先判断cmd + strlen(cmd) < str_end，别拿越界指针做减法。

5.2 表达式求值：结果类型和打印格式对不上

现象：p 0x80000000打印出-2147483648；p 0x80000000 + 1打印出-2147483647，而背后内存里明明是0x80000001。

原因：word_t是uint32_t，但 printf 用了%d。类型和格式符不匹配在 C 里是未定义行为，实际表现就是最高位被当成符号位解释。这不是求值错了，是显示错了——但显示错了会让人以为是算术错了。

解决：涉及word_t的打印统一用%u或0x%08x，二进制位模式一目了然。如果确实要按有符号解释（比如比较-1 < 0），显式强转成sword_t，别指望格式符替你转。

5.3 断点：命中判定做了，但永远不会停

现象：b 0x80000000之后执行c，程序一路跑到结束，断点形同虚设。

原因：比较的时机错了。exec_once里s->pc = pc记的是执行前的地址，指令执行完后s->pc已经被改成了下一条的地址。如果在循环里比较的是cpu.pc，那拿到的一直是「即将执行的下一条」，永远比断点表里的值超前一条。另一种原因是断点地址存的是宿主机指针，而比较用的是客户机地址，两边差着一个CONFIG_MBASE。

解决：把断点判定放在execute循环里、exec_once调用之前，参数用函数入参cpu.pc而不是执行后的值；断点表里统一存vaddr_t，不要混入任何pmem相关的指针运算。

提示：如果你在调试时发现断点「有时灵有时不灵」，先打印一行pc看看它和断点地址差多少，通常差值就是一条指令长度，这就是判定时机的锅。

5.4 单步：si 之后 pc 纹丝不动

现象：连续si三次，info r里的 pc 一直没变，或者只在两个地址之间来回跳。

原因：三种可能。一是某个 exec 函数里手动改了s->pc但忘了这会被exec_once末尾的cpu.pc = s->pc覆盖掉，两边打架；二是指令本身是跳转指令，跳回自己，那属于客户程序死循环，模拟器行为正确；三是inst_fetch里忘了*pc += len，取指后 pc 没推进，下一条还在原地。

解决：先确认是不是第三种的锅——单独打一条日志，打印exec_once入参的 pc 和出参的 pc，如果两者相等且指令不是跳转，基本可以断定是写完回。至于跳转指令，si之后 pc 变化反而是对的，别急着改代码。

5.5 内存扫描：x 命令读到不该读的地方

现象：x 16 0x80000000读到一半程序直接段错误退出，或者打印出一片0xcd。

原因：x的循环里没有做边界检查，addr + len越过CONFIG_MBASE + CONFIG_MSIZE之后，guest_to_host算出的指针落到了pmem数组外面，读写它就是宿主机层面的越界。0xcd是调试版运行时填充的内存标记，说明你读的是未初始化区域而不是真实数据。

解决：在x里对每个要读的地址走vaddr_read，别绕过它自己算指针——那样才享受得到in_pmem的判断和越界报错。如果确实想支持「读到边界就截断」的友好行为，在循环里加一条if (!in_pmem(addr)) break;，并在退出时提示剩余字节数。

6. 设计取舍：为什么基础设施比功能更值钱

6.1 几种实现选择的代价

把 PA1 里的几个关键决定摊开看，会发现它们都不是唯一解，而是一组「先保证什么」的排序：

这张表里没有「更好的方案」，只有「在这个阶段更值的方案」。解释执行比 JIT 慢一到两个数量级，但 PA1 的目标是让每条指令的行为都可见、可停、可回放，编译成函数序列就把这个能力弄丢了。平坦数组在客户机内存配得很大时很浪费，但它让「访存」退化成一个下标运算，整个模拟器最热的那条路径因此干净得不像话。

6.2 一个可以自证的验证方法

想知道自己实现的 sdb 是不是真的对，不需要等后面的测试用例，用模拟器自己验证自己就行：写一小段机器码塞进pmem，然后si若干次，每次用p $pc和info r观察状态转移是否符合手工推演。比如一条自增后跳回自身的指令，si三次应该看到 pc 在两个地址之间规律摆动、目标寄存器每次加一。如果推演和执行不一致，问题一定在你这边——因为解释执行没有隐藏状态，每一步都是显式的。这套自证的思路，比事后对日志高效得多。

真要挑一个 PA1 里最值钱的东西，我会选那层vaddr_read空壳。当时写的时候觉得它多余，一个函数只做转发，纯属浪费。等后面接上分页、接上设备、接上越界检查，才发现所有调用方一行没改，全部自动获得了新能力。从那以后我每次动手写新模块，都会先问自己一句：这层壳今天是空的，但它明天要挡住什么？希望帮到你。

本文还有配套的精品资源，点击获取