企业官网建设流程全解析

ADDI 这条指令大概是所有 RISC 汇编里最早学会、也最容易被跳过去的一条。语法只有三个操作数，语义就是加法，很多人在第一小时就觉得自己掌握了它；但等到真正去读启动代码、调栈帧、追一个指针跑飞的 bug 时，才发现自己踩的坑十有八九都跟这一条指令有关。ADDI 全称是 add immediate，把源寄存器的值加上一个编码在指令内部的立即数，结果写回目的寄存器。它看着平平无奇，实际承担着栈指针调整、局部变量寻址、常量装载、寄存器清零、函数返回值构造这一类每天都在发生的工作，是整个指令集里出现频率最高的几条指令之一。这篇内容面向三类人：刚接触汇编、想弄明白一条指令从文本到机器码到底经历了什么的新手；正在写启动代码、链接脚本或者手写汇编的嵌入式开发者；以及需要读反汇编、做性能分析、排查崩溃现场的工程师。我会把 ADDI 的编码结构、立即数边界、伪指令展开、溢出语义、工具链行为全拆一遍，配上可以照着敲的例子和我自己踩过的坑。

1. ADDI 的设计逻辑：一条"带常量"的加法

1.1 三操作数格式与它的真实读法

ADDI 的标准写法是addi rd, rs1, imm，语义是x[rd] = x[rs1] + sext(imm)。这里面有三个细节值得单独拎出来说。第一，它是三操作数指令，目的寄存器和源寄存器是分开的，rd和rs1可以指向同一个寄存器，这时候看起来就像"就地累加"，addi x5, x5, 1这种写法在循环里极其常见。第二，立即数是符号扩展之后再参与运算的，不是零扩展，这一点决定了它能表示负数，也决定了它的取值范围是 [-2048, 2047]，而不是 [0, 4095]。第三，它属于 I 型（immediate type）编码格式，同一个格式被 load、jalr 和整组立即数运算指令共用，所以你在看机器码的时候，光看字段布局分不出这是addi还是lw，必须结合opcode和funct3才能定性。

从指令集设计者的角度，为什么不让add直接支持立即数？因为在定长 32 位编码里，寄存器字段每个要占 5 位，两个源寄存器加一个目的寄存器就是 15 位，剩下的 17 位要放操作码和立即数。如果你想让一条指令同时支持"寄存器-寄存器"和"寄存器-立即数"两种形态，就必须在操作码或者功能位里做区分，否则译码器无法判断那 12 位到底是寄存器编号还是立即数。分开发一条独立指令，编码干净、译码简单、硬件复用度高，代价只是操作码空间多花一个槽位——这笔账在任何一款 RISC 指令集里都划算。

1.2 为什么它比"先装载再相加"更值得存在

有人会问，既然已经有add了，为什么不先li一个临时寄存器再add？答案藏在指令条数和寄存器压力两件事里。假设你要给栈指针减 32，用两步写法是li t0, 32加sub sp, sp, t0，两条指令、一个临时寄存器；用 ADDI 是一条addi sp, sp, -32，一条指令、零个临时寄存器。在函数入口和出口这种高频路径上，省一条指令就是省一次取指、一次译码、一次执行，对一个每秒执行上亿条指令的处理器来说这不是小事。更关键的是临时寄存器是稀缺资源，函数序言里往往已经把能用的寄存器都用满了，此时再挤一个出来做常量中转，很可能逼着编译器多 spill 一次，把省下来的开销又还回去。

再往深一层看，li这个伪指令本身在小常量场景下就是直接展开成addi rd, x0, imm的。也就是说，"先装载再相加"的路径里，装载那一步本来就在用 ADDI。既然绕不开它，不如把它做成原生的算术指令，让常量加法一步到位。这个设计思路在很多指令集里是一致的，只是立即数位宽和编码方式各有取舍，我在后面会拿它和另一类采用"8 位数值加循环移位"编码的经典 RISC 架构做对比。

1.3 12 位立即数是怎么定下来的

立即数位宽的选择是一个典型的折中问题。位宽越大，能直接表达的常量范围越广，需要组合指令的场景越少；但位宽越大，留给寄存器和操作码的空间就越小。12 位是这么算出来的：32 位总长减去 7 位主操作码，再减去 5 位rs1、5 位rd、3 位funct3，正好剩下 12 位。这 12 位作为有符号数，范围就是 -2^11 到 2^11-1，也就是 -2048 到 2047。

对比一下：如果只留 8 位立即数，范围只有 -128 到 127，栈帧稍微大一点、数组偏移稍微远一点就得拆成两条指令，代码密度会明显变差；如果扩到 16 位，就得砍掉funct3或者压缩操作码，整组 I 型指令的扩展性就没了。12 位是一个"够用且不挤"的位置，实测下来绝大多数函数栈帧、结构体字段偏移、循环小常量都落在这个区间内。另外还有一个容易被忽略的硬件细节：这套编码把所有立即数格式的符号位都对齐放在指令的第 31 位。I 型的imm[11]在 bit31，S 型的imm[11]也在 bit31，B 型和 J 型同样如此。这样硬件在译码时只需要看inst[31]一个信号，就能决定要不要对整个立即数做符号扩展，不用为每种格式写一套独立的扩展逻辑。这种"格式不同但符号位对齐"的手法，是读指令集手册时最值得留意的设计巧思之一。

2. 从汇编文本到 32 位机器码

2.1 I 型字段布局逐位拆解

把一条 ADDI 拆开，32 位是这样分配的：

这里有个特别容易记混的点：rs1在rd的左边（高位），rd在低位。刚开始手算机器码的时候我经常把这两个字段的位置写反，导致反汇编出来寄存器全错位，明明写的是addi x5, x6, -100，objdump 反出来变成了addi x6, x5, -100，看起来像是汇编器出了问题，其实就是自己算错了位。养成习惯：先写立即数占高 12 位，再写rs1占 19:15，funct3占 14:12，rd占 11:7，最后补opcode，从高到低排一遍就不会错。

还有一点：funct3 = 000加上opcode = 0010011这个组合，只对应 ADDI 一条指令。同组的SLTI（010）、SLTIU（011）、XORI（100）、ORI（110）、ANDI（111）都靠funct3区分；而SLLI、SRLI、SRAI虽然funct3是 001 和 101，但它们的立即数区被拆成了shamt加funct7两部分，语义完全不同。调试时如果看到funct3 = 001却按 ADDI 去解读立即数，结果一定对不上，这是读原始机器码时的经典误区。

2.2 手工编码的完整计算过程

拿一个真实例子走一遍：addi x5, x6, -100。

第一步，把 -100 转成 12 位补码。-100 的绝对值是 100，二进制0000 0110 0100（12 位表示），取反加一得到1111 1001 1100，也就是十六进制的0xF9C。验证一下：0xF9C作为 12 位有符号数是 0xF9C - 0x1000 = 3996 - 4096 = -100，正确。

第二步，把各字段左移到对应位置。立即数左移 20 位：0xF9C << 20 = 0xF9C00000；rs1 = 6左移 15 位：6 << 15 = 0x00030000；funct3 = 0左移 12 位还是 0；rd = 5左移 7 位：5 << 7 = 0x00000280；opcode = 0x13保持不变。

第三步，全部按位或起来：0xF9C00000 | 0x30000 | 0x280 | 0x13 = 0xF9C30293。这条指令的最终机器码就是0xF9C30293。我一般会把这个过程写成一个小脚本，避免反复手算出错：

def encode_addi(rd, rs1, imm): assert -2048 <= imm <= 2047, f"立即数 {imm} 超出 12 位有符号范围" imm12 = imm & 0xFFF # 截成 12 位，负数自动补码 return ((imm12 << 20) | (rs1 << 15) | (0 << 12) | # funct3 = 000 (rd << 7) | 0x13) def decode_addi(inst): imm = inst >> 20 if imm & 0x800: # 符号位在 bit11 imm -= 0x1000 rs1 = (inst >> 15) & 0x1F rd = (inst >> 7) & 0x1F return rd, rs1, imm print(hex(encode_addi(5, 6, -100))) # 0xf9c30293 print(decode_addi(0xF9C30293)) # (5, 6, -100)

这段脚本里最值得看的是imm & 0xFFF和编码函数里的 assert。前者保证负数也能正确落到 12 位的补码表示里，后者是防线——宁可让脚本报错，也不要在超出范围时悄悄产生一条错误的机器码。写工具脚本时我一律坚持这个原则：边界检查必须显式失败，不要做静默截断。

2.3 用反汇编器验证你的手算结果

手算完机器码，一定要用工具验证，别相信自己的算术。流程很简单：把十六进制数写进一个文本文件，用交叉工具链反汇编。

# 把机器码写进文件 printf '\x93\x02\xc3\xf9' > one.bin # 反汇编（-D 表示整个文件都当代码处理，-b 指定二进制输入格式） riscv32-unknown-elf-objdump -D -b binary -m riscv:rv32 one.bin

输出里应该能看到addi x5, x6, -100。注意这里字节序是小端，0xF9C30293落盘顺序是93 02 C3 F9（低位字节在前），写反了就会反出另外一条指令。我第一次做这个练习的时候就写成了大端序，反汇编出来是个看不懂的东西，检查了半天才意识到问题出在字节序上，而不是编码算错了。

反汇编这一步的价值不只是"验证对不对"，更重要的是训练查错能力。当你手上有机器码、有反汇编结果、有原始汇编文本这三份东西，任何一处不一致都说明中间某个环节有问题，而这个定位过程本身就是最有效的学习。

3. 边界、溢出与伪指令：真正的坑都在这

3.1 硬边界就在 -2048 和 2047

这是 ADDI 最容易翻车的地方。写addi x5, x6, 2048，汇编器会直接报错，类似 "immediate out of range" 或者 "illegal operands" 的提示，具体措辞各家工具链略有差异。麻烦的是，有些汇编器在遇到伪指令形式的add x5, x6, 2048时会自动帮你展开成多条指令，而遇到真正的addi时不会。这就造成一种很迷惑的现象：同一个数字，写成add能过，写成addi就报错。

我的建议是：永远不要依赖汇编器帮你展开。理由很实际——自动展开意味着你看到的汇编行和最终生成的指令不是一一对应的，调试器里单步的时候会多出几条你没写过的指令，而且展开后的临时寄存器是由汇编器分配的，可能占用你以为"空闲"的寄存器。写关键路径代码时，我宁愿手动拆成lui+addi，明确知道自己在干什么。

还有一个更隐蔽的情况：偏移量的边界判断是按字节算的，不是按元素个数。给一个结构体数组做索引，元素大小 64 字节，那么能直接寻址的元素个数只有 2048/64 = 32 个。写代码时脑子里想着"数组就几十个元素，肯定在范围内"，实际编译的时候偏移早就越界了。这类问题在手动展开的 memset/memcpy 循环里尤其常见。

3.2 溢出行为：不陷阱，直接回绕

ADDI 对溢出的处理是静默回绕，按当前位宽截断，不产生异常、不置标志位。0x7FFFFFFF + 1的结果就是0x80000000，处理器不会给你任何提示。这和某些架构在溢出时触发陷阱的做法正好相反，也意味着你不能靠硬件帮你发现整数溢出。

这件事和 C 语言层面的语义要严格区分开。C 里对signed int做溢出属于未定义行为，编译器完全可以假设"溢出不会发生"，进而做出各种激进的优化；而在汇编层，溢出是明确有定义的——按位截断。两层语义不一致，正是很多"编译器优化后行为变了"类 bug 的根源。我遇到过的一个典型场景是：一段手动写的定点数累加，C 代码里有符号溢出，编译器把判断条件优化掉了，改成汇编实现之后再测，现象完全不一样。排查了半天才反应过来，问题不在汇编写错了，而在于 C 层的未定义行为本来就不该被依赖。

顺带提醒一句，无符号和有符号的溢出在硬件层面没有区别，都是同一套加法电路，区别只在编译器和你的程序怎么解释那些比特。所以写汇编的时候不要问"这是有符号还是无符号加法"，ADDI 只有一种加法。

3.3 一堆伪指令背后都是 ADDI

汇编里大量看起来不像 ADDI 的写法，展开之后全是它。这个表我建议直接记住：

mv展开成addi rd, rs, 0这件事很值得琢磨。为什么不设计一条专门的寄存器传送指令？因为加了 0 就是传送，硬件加法器天然支持，省一个操作码。nop同理，加 0 写到零号寄存器，什么都不改变。这种"用已有指令的退化形式实现新功能"的思路，是 RISC 设计的典型风格：不增加指令，只增加用法。

这里面唯一需要小心的是li。当常量超过 12 位范围时，它不再展开成单条 ADDI，而是展开成lui加addi的组合，甚至更多条（针对 64 位常量）。如果你在调试器里看到自己写的li变成了两条指令，不要奇怪，这是正常行为，具体展开规则我在第 4.4 节会详细算一遍。

3.4 零号寄存器的三个妙用

零号寄存器的值恒为 0，写入无效，读出来永远是 0。这个设计让 ADDI 多了几种非常顺手的用法。第一种是清零：addi x5, x0, 0把 x5 置零，不需要专门的清零指令。第二种是加载小常量：addi x5, x0, -1得到全 1，这比构造一个常量再传送省事得多。第三种是构造立即数比较：判断一个值是否等于某个小常量，可以先addi t0, x0, K再用beq比较，也可以直接addi t0, rs, -K再用beqz判零，后者少一条指令。

零号寄存器还有一个好处是给编译器提供了确定的安全目标。当某个计算的结果不需要保留时，编译器可以放心地把rd指向 x0，既完成了指令编码又不污染任何状态。你在反汇编里偶尔会看到"写 x0"的指令，那不是 bug，是刻意的丢弃。

4. 完整实操：写、编、跑、验一遍

4.1 准备一套最小可用的环境

不需要开发板，一台普通电脑就够。需要三样东西：交叉汇编器（把 .s 变成 .o 或者直接出二进制）、反汇编器（验证）、模拟器（真正执行）。常见的开源工具链都能提供前两样，模拟器可以用指令集模拟器，也可以用带裸机运行能力的模拟器。下面是典型的编译命令组合：

# 只汇编不链接，产出目标文件 riscv32-unknown-elf-as -march=rv32i -mabi=ilp32 -o demo.o demo.s # 反汇编目标文件，能看到每条指令的机器码 riscv32-unknown-elf-objdump -d demo.o # 直接提取纯二进制（裸机场景用） riscv32-unknown-elf-objcopy -O binary demo.o demo.bin

关键参数解释一下：-march=rv32i指定基础整数指令集，如果你用了乘除法指令会报错，这时候再看具体芯片支持哪个扩展；-mabi=ilp32指定调用约定，32 位整数、32 位指针、没有浮点。这两个参数必须匹配，写错了会在链接阶段报 ABI 不兼容，或者更糟——链接过了但运行行为诡异。我踩过的一次就是 march 写成了带压缩指令扩展的版本，但模拟器只支持基础指令集，结果执行到被压缩过的指令时直接卡死，现象看起来像是死循环，实际上是模拟器不认识那条 16 位编码。

4.2 写一个能验证边界的小程序

下面这段代码专门用来验证 ADDI 的各种边界行为，每一行都值得在模拟器里单步确认：

.section .text .globl _start _start: addi x5, x0, 2047 # 立即数正向上界，x5 = 2047 addi x6, x0, -2048 # 立即数负向下界，x6 = -2048 addi x7, x5, 1 # 2047 + 1 = 2048，不溢出 addi x8, x6, -1 # -2048 - 1 = -2049，不溢出 addi x9, x0, -1 # 全 1，即 0xFFFFFFFF addi x10, x9, 1 # 0xFFFFFFFF + 1，回绕成 0 addi x11, x5, 0 # 等价于 mv x11, x5 addi x0, x0, 0 # nop，什么都不改 addi x12, x0, 0 # 显式清零 addi sp, sp, -16 # 典型栈帧分配 addi sp, sp, 16 # 典型栈帧回收

跑完这段，寄存器快照应该是：x5 = 2047、x6 = -2048、x7 = 2048、x8 = -2049、x9 = 0xFFFFFFFF、x10 = 0、x11 = 2047、x12 = 0。这里最值得盯的是 x10：加法的结果本该是 4294967296，超出了 32 位，硬件直接截断成 0。整个过程没有任何提示，如果你是靠"结果会变大所以我检查一下"来做逻辑，这就是个隐患。

x8 那条也值得注意：-2048 - 1的结果 -2049 是允许的，因为立即数范围限制的是操作数，不是结果。很多人会把这两件事混淆，以为结果也不能超范围，实际上只要参与运算的立即数在 -2048 到 2047 之间，结果可以是任何 32 位值。

4.3 在模拟器里单步观察

加载二进制之后，逐条执行，重点看三个东西：PC 增量是否为 4（没有压缩指令的情况下）、目的寄存器的值变化、以及写零号寄存器时是否真的什么都没发生。最后这一点在多数模拟器里会显示成"写 x0 被忽略"，如果没有这个行为，说明模拟器实现有问题。

单步的时候还有一个技巧：把反汇编窗口和寄存器窗口对照着看。反汇编显示的是addi x5, x6, -100，你脑子里应该马上能算出这条指令的机器码长什么样，以及它会让 x5 变成什么。练到能看着汇编行直接报出机器码的程度，读启动代码会轻松很多，因为启动代码里大量是这种小常量运算，没有宏观语义可依赖，只能一条条读。

如果手边没有支持单步的模拟器，退一步的做法是把程序编译出来直接反汇编，对着机器码验证自己的手算，虽然看不到寄存器变化，但至少能验证编码逻辑。我早期就是这么练的，效果也不差。

4.4 大立即数怎么装：li 的展开规则与补偿计算

常量超过 12 位范围时，需要拆成两条：lui负责高 20 位，addi负责低 12 位。这里有个非常关键、也非常容易错的细节：addi的低 12 位是符号扩展的，如果它的最高位（第 11 位）是 1，实际参与运算的值就是负的，所以lui装载的高位必须额外加 1 来补偿。

拿 0x12345ABC 举例。低 12 位是 0xABC，展开成二进制1010 1011 1100，第 11 位是 1，说明按符号扩展它会变成负数，实际值是 0xABC - 0x1000 = -0x544。所以正确写法是：

lui x5, 0x12346 # 注意是 0x12346，不是 0x12345 addi x5, x5, -0x544 # 或者写成 addi x5, x5, 0xABC，汇编器会处理

验算：0x12346 << 12 = 0x12346000，减去0x544等于0x12345ABC，正确。如果偷懒写成lui x5, 0x12345加addi x5, x5, 0xABC，实际得到的是0x12345000 - 0x544 = 0x12344ABC，整整少了 0x1000，偏移错了 4096 字节。

再看一个不需要补偿的例子：0x12345345。低 12 位 0x345 的第 11 位是 0，所以不用补偿，直接lui x5, 0x12345加addi x5, x5, 0x345就对了。

我把规则整理成一张表，判断的时候照着查：

手工算的时候还有一个更省事的办法：直接把目标值写成"某个 4096 的倍数 加上 一个落在 -2048 到 2047 之间的偏移"。比如 0x12345ABC，我想找一个接近它的、且是 4096 倍数的值，0x12346000 就是（因为 0x12346000 的低 12 位全是 0），那么偏移就是 0x12345ABC - 0x12346000 = -0x544，落在范围内，于是lui用 0x12346、addi用 -0x544。这个思路比"先判断第 11 位再决定补偿"更直观，也更不容易算错。

实际写汇编的时候，我基本不手算这个，直接写li x5, 0x12345ABC，让汇编器展开，然后用objdump -d看它到底展开了什么，再核对一遍。核对这一步不能省，因为我确实遇到过不同版本工具链在极少数边界值上展开策略不一致的情况，尤其是接近 2 的 31 次方那些值，看一遍心里踏实。

5. 真实代码里的 ADDI：读反汇编的正确姿势

5.1 重定位符号与链接期填充

在可执行文件里，你经常会看到这样的组合：

auipc a0, 0x1 addi a0, a0, 120

这两条合起来是在算一个全局变量的地址，auipc取当前 PC 加上高位偏移，addi补上低位偏移。用伪指令写的时候是la a0, symbol，汇编器把它拆成这两条，并且留下重定位记录，具体数字等链接器来填。这就意味着在目标文件里看到的立即数不等于最终运行时的值，你在 .o 上反汇编看到的和链接后的可执行文件里看到的可能完全不同。

排查这类问题时有个顺序：先看 .o 反汇编确认指令序列对不对，再看链接后的可执行文件反汇编确认立即数被填进来了，最后才怀疑运行环境。我遇到过一次"地址算错"的诡异 bug，查到最后发现是链接脚本里某个段的基址改动过，而代码里用了一个硬编码的绝对值做比较，两边对不上——ADDI 本身一点问题都没有，问题在于我盯着它看了半天。

另外，%hi和%lo这类修饰符的处理也是链接期完成的，%hi会自动包含前面说的那个"+1 补偿"，不需要你手动加。手写内联汇编的时候如果不写这层修饰符、直接写数字，那就得自己负责补偿逻辑。

5.2 函数序言和尾声里它是绝对主角

任何一次函数调用，几乎必然出现这样的模式：

func: addi sp, sp, -32 # 序言：分配栈帧 sw ra, 28(sp) sw s0, 24(sp) addi s0, sp, 32 # 建立帧指针 ... lw ra, 28(sp) lw s0, 24(sp) addi sp, sp, 32 # 尾声：回收栈帧 ret

这里面每一条 ADDI 都有明确意图。addi sp, sp, -32是分配栈帧，用减法因为栈向下生长；addi s0, sp, 32是把帧指针设回调用前的栈顶位置，方便后续用正偏移访问参数。注意序言和尾声的两条 ADDI 是必须严格对称的，一正一负、绝对值相同，少了对不上就会出现栈失衡，表现出来就是函数返回后跑飞或者数据被踩。

调试栈失衡有个很好用的手法：在函数入口和出口各设一个断点，看 sp 的值是否回到进入时的一样。如果不等，直接往上翻这个函数里的所有 sp 相关操作，八成是有条分支路径提前 return 了但没走尾声。这种情况在有多处 return 的 C 函数里编译出来的汇编里很常见，编译器通常会把尾声复制到每个 return 分支，但手写汇编时很容易漏掉一条分支。

另一个容易忽视的细节是栈帧大小必须 16 字节对齐，这是调用约定要求的。所以你会看到addi sp, sp, -48、addi sp, sp, -64这类数值，很少见到-50。如果你手写汇编时随便填了个-36，单看这一条指令没问题，但破坏了 ABI 对齐要求，调用库函数时可能直接崩在某个向量化的内存操作上。

5.3 和 load/store 共用格式带来的混淆

load 和 store 的地址偏移，跟 ADDI 的立即数用的是同一套 12 位 I 型编码（store 用的是 S 型，但位宽一致）。这意味着lw x5, -100(x6)和addi x5, x6, -100的立即数部分完全一样，只在opcode和funct3上有区别。手算机器码或者看裸机器码的时候，如果只盯着立即数字段，会完全分不清这两条指令。

所以我在做机器码分析时，第一步永远是先提取opcode判断大类，再看funct3确定具体指令，最后才去解释立即数和寄存器。这个顺序不能乱。有一次我拿到一段固件里提取出来的数据，按 ADDI 解读了半天，最后发现那一段根本不是代码，是数据表，被误当成代码反汇编了——指令集里没有魔数保护，任意 32 位数据都是一条"合法"指令，这是所有定长指令集共同的陷阱。

6. 踩坑记录与排查速查表

6.1 现象与根因对照

下面这张表是我这些年遇到的、和 ADDI 直接相关的问题汇总，按出现频率排序：

表格里的第三条和第四条是我认为最值得提前知道的。栈帧不对称和对齐破坏这两类问题，症状都很"远"——崩溃点通常不在出问题的函数里，而是在它调用或者被调用的某个完全不相关的库函数里，因为栈被搞坏之后，下一次压栈或者返回就会落在错误的位置上。排查这类问题不要顺着崩溃点往上找，直接从栈指针的值入手，比对着已知正确的值去查更快。

6.2 我常用的三个排查手法

第一个手法是算十六进制差值。当怀疑偏移算错时，把错误值和正确值都打印出来做减法。如果差值正好是 0x1000 的整数倍，几乎可以立刻确定是 lui/addi 的符号补偿问题；如果差值是 4 或者 8，那更可能是某条指令被漏掉或者多算了。这个技巧简单到有点笨，但那么多年下来，它帮我定位的问题比任何高级调试器都多。

第二个手法是在可疑位置插 nop。当你怀疑某条指令没执行或者执行了两次，在它前后各插几条 nop，然后看反汇编里的位置和调试器里的 PC 是否吻合。nop展开就是addi x0, x0, 0，对状态零影响，插了绝对安全。这个方法在分析被编译器优化过的代码时特别有用，因为优化会重排、合并、删除指令，你没法靠行号对应，只能靠插入标记来定位。

第三个手法是用零号寄存器做无害验算。想确认某条 ADDI 的立即数被解释成了什么，把它改成addi x0, rs1, imm的形式执行一遍，然后看下一条指令的 PC 有没有按预期走，或者用一个不影响的寄存器接收结果。写零号寄存器永远不会改变机器状态，是个绝对安全的白盒探测点。

6.3 几条不写在手册里的经验

先说最重要的一条：不要把立即数边界当成"很少会碰到"的事情。栈帧稍微大一点、结构体稍微复杂一点，就会超过 2047。我见过一个自动生成的代码生成器，因为没做范围检查，在结构体字段数超过某阈值之后产出的代码全部偏移错误，而错误表现是"读到了另一个字段的值"，看起来像是逻辑 bug，实际是编码问题。生成代码的工具一定要显式检查立即数范围，超出就拆成两条。

第二条是关于寄存器的：addi rd, rs, 0不是冗余指令。虽然它对值没有影响，但它在指令流里有实际意义——可以当占位、可以当分支目标的对齐、可以让调试器有个稳定的断点位置。编译器在调试版本里经常保留这类指令，别急着把它优化掉，除非你在做尺寸敏感的优化。

第三条和可读性有关：手写汇编时，宁可多写几行注释把立即数的含义写清楚，也不要依赖"看代码能推出来"。半年后回来看addi sp, sp, -88，你根本不会记得那个 88 是怎么算出来的，是 8 个 8 字节槽加 24 字节局部变量，还是别的什么组合。我现在固定用注释标出每一项的构成，例如写成# -88 = 8*8(保存区) + 24(局部变量)，排查栈问题时能省掉大量时间。

最后一条是心态上的：这条指令看起来太简单，所以出了问题之后大家往往先去查逻辑、查内存、查并发，最后才回头看它。但以我的经验，越简单的指令出错越隐蔽，因为它不符合"出错的地方应该复杂"这个直觉。真遇到查不动的偏移错误，把相关的那几条 ADDI 单独拎出来，逐位算一遍机器码，往往十分钟就能把几个小时没找到的问题揪出来。