MIPS指令集符号扩展与零扩展：lb与lbu的深度解析

MIPS 指令集里有一类细节，平时写高级语言几乎碰不到，但只要开始看汇编、调编译器后端、或者做指令级模拟器，就一定会被它绊一下：同一条加载指令，为什么有时候是lb，有时候是lbu？两个字母之差，结果可能从 0 变成 -1，从 255 变成 -1，甚至让一个循环提前退出。我第一次在模拟器里跑一段字节处理代码时就栽在这上面——内存里明明是0xFF，读进寄存器却变成了0xFFFFFFFF，后面所有算术全乱套。

这篇内容就围绕MIPS 指令集中的符号扩展与零扩展展开，从lb和lbu这对最容易混淆的指令切入，把"为什么要扩展""扩展的规则是什么""哪些指令用哪种扩展""写代码时怎么选"这几件事讲透。适合正在学计算机组成原理、写 MIPS 汇编、做指令集模拟器，或者单纯想搞明白"寄存器是 32 位、内存按字节寻址"这件事到底怎么衔接的读者。哪怕你之前没系统学过指令集，跟着往下看也能理清逻辑。

1. 先搞清楚 lb 和 lbu 到底差在哪

1.1 一条指令的完整语义拆解

lb是 Load Byte 的缩写，lbu是 Load Byte Unsigned。两者做的事情在"取数"这一步完全一样：从内存中某个地址取出一个字节（8 位），放进目标寄存器的低 8 位。真正的分歧发生在"放进寄存器之后"——寄存器是 32 位的，剩下那 24 位怎么办？

这就是扩展问题的全部来源。MIPS 的通用寄存器宽度是 32 位，而内存是按字节编址的，一次字节加载只拿到 8 位有效数据，必须把 8 位"撑"成 32 位才能参与后续运算。撑的方法有两种：

• 符号扩展（sign extension）：把被加载字节的最高位（第 7 位，也就是符号位）复制到高 24 位。如果这个字节是0x80到0xFF，最高位是 1，高 24 位全填 1；如果是0x00到0x7F，最高位是 0，高 24 位全填 0。
• 零扩展（zero extension）：不管字节内容是什么，高 24 位一律填 0。

lb用的是符号扩展，lbu用的是零扩展。就这么点区别，但它决定了这个字节被当成"有符号数"还是"无符号数"来对待。

举个具体例子。假设内存地址0x10010000处存着字节0xFF：

同样是读一个字节，lb得到的是十进制的 -1，lbu得到的是 255。如果你后面拿这个值去做数组下标、做循环计数、做地址偏移，这两个结果的走向会完全不同。

1.2 为什么"符号位"这件事值得单独设计一条指令

有人可能会问：既然零扩展更"安全"，为什么不干脆只保留lbu，让所有字节加载都零扩展？反过来，为什么还要留一个会产生负数的lb？

答案在于数据本身有没有符号语义。计算机里存的都是比特，符号是我们赋予的解释。一个字节0xFF，在无符号语境下是 255，在有符号语境下是 -1，两种解释都合法，取决于这个字节代表什么：

• 如果它是一张图片的像素灰度值、一个 ASCII 字符、一个布尔标志，那它是无符号的，用lbu才对。
• 如果它是一个温度采样值（可能为负）、一个音频波形的差分、一个有符号的小整数，那它是补码表示的有符号数，必须用lb才能保住负号。

指令集设计者没法替程序员判断语义，所以干脆提供两条指令，把选择权交出去。这也是 RISC 设计哲学的体现：硬件不做猜测，语义由软件显式表达。理解了这一点，你就明白lb/lbu不是冗余设计，而是把"符号解释权"下放给了写代码的人。

提示：判断用哪条指令，问自己一句"这个字节可能是负数吗"。可能是负数，用lb；只可能是 0 到 255 的非负数，用lbu。这个判断标准比背指令表管用得多。

2. 符号扩展的硬件逻辑：一条线复制 24 份

2.1 从 8 位到 32 位的连线方式

符号扩展在硬件上极其简单，简单到有点反直觉——它不需要任何逻辑门做运算，本质上就是布线。把输入的第 7 位（最高位）用导线扇出，同时接到输出的第 8 位到第 31 位，一共复制 24 份。输入的低 8 位原样接到输出的低 8 位。完事。

用伪代码描述这个组合逻辑：

// 符号扩展：8 位输入 -> 32 位输出 assign out[7:0] = in[7:0]; assign out[31:8] = {24{in[7]}}; // 把符号位复制 24 次

零扩展更简单，高 24 位直接接常量 0：

assign out[7:0] = in[7:0]; assign out[31:8] = 24'b0;

正因为实现成本几乎为零，MIPS 才敢在数据通路里到处放扩展单元。你在看 MIPS 单周期数据通路图时，会看到 ALU 的一个输入端前面挂着一个"Sign Extend"模块，它负责把 16 位的立即数扩展成 32 位再送进 ALU。这个模块和lb用的符号扩展是同一套逻辑，只是输入位宽不同（16 位扩展到 32 位，复制的是第 15 位）。

2.2 扩展位宽变化时，复制的永远是"最高有效位"

这里有个容易记混的点：符号扩展复制的不是"第 7 位"这个固定位置，而是当前数据位宽下的最高位。8 位数据复制第 7 位，16 位数据复制第 15 位，道理完全一样。

所以当你看到addi $t0, $t0, -1这种指令时，立即数-1在指令里只占 16 位（编码为0xFFFF），送进 ALU 前要符号扩展成 32 位的0xFFFFFFFF。如果错误地用了零扩展，0xFFFF就变成了 65535，一条"减 1"的指令会变成"加 65535"，程序直接跑飞。这也是为什么 MIPS 的addi、lw/sw的地址偏移、所有分支指令的偏移量，统统采用符号扩展——它们处理的都是有符号的量（负立即数、负偏移）。

2.3 一个常被忽略的细节：扩展发生在"读进寄存器"那一刻

很多人以为扩展是"用的时候才发生"，其实不是。对lb/lbu来说，扩展发生在数据从内存写回寄存器堆的那一拍，写进去的就是扩展后的 32 位值。之后你在寄存器里看到的、参与运算的，已经是完整的 32 位数了。

这个时序细节在写模拟器时特别关键。如果你在模拟器里把"加载字节"实现成"只改寄存器低 8 位、高 24 位保持不变"，那就错了——正确行为是整个 32 位寄存器被覆盖。我见过有人这么写，结果寄存器里残留的高位垃圾数据导致后续比较莫名其妙地失败，排查了大半天才定位到这一行。

3. 不止 lb/lbu：MIPS 里扩展规则的完整地图

3.1 加载类指令的扩展对照表

lb/lbu只是最容易撞见的一对，MIPS 的加载指令家族里，扩展规则是按"数据宽度 + 有无符号"两个维度组合出来的。把这张表记住，加载类指令基本就不会选错了：

注意lw那一行——它一次读满 32 位，寄存器宽度正好匹配，根本不存在扩展问题。这也从侧面说明：扩展问题的根源就是"加载宽度小于寄存器宽度"。宽度一旦对齐，符号与否就无从谈起了。

3.2 立即数、分支、地址偏移：那些"隐形"的符号扩展

除了加载指令，MIPS 里还有一大批地方默默做着符号扩展，只是它们不叫lb/lbu，容易被忽略：

• addi/addiu的立即数：16 位立即数符号扩展成 32 位。注意addiu虽然名字带 u（unsigned），但它的立即数仍然做符号扩展，这个"u"指的是"不检测溢出"，不是"无符号扩展"。这是 MIPS 里最经典的命名陷阱之一，考试和面试都爱考。
• lw/sw的地址偏移：16 位偏移量符号扩展后与基址寄存器相加，所以偏移可以是负数（往低地址方向访问）。
• 分支指令的偏移：beq/bne的 16 位偏移符号扩展后左移 2 位，再与 PC 相加，支持向前和向后跳转。
• andi/ori/xori的逻辑立即数：这几个反而用零扩展，因为按位逻辑运算里高位补 0 才符合直觉，补 1 会把无关的高位污染掉。

把这张"隐形扩展地图"理清楚，你会发现 MIPS 的扩展规则其实高度一致：算术和地址相关的用符号扩展，逻辑和位操作相关的用零扩展。抓住这条主线，比死记每个指令的规则靠谱。

3.3 为什么逻辑指令偏偏用零扩展

andi用零扩展这件事值得单独说一句，因为它和addi形成了鲜明对比，很多人第一次见会愣一下。

原因还是语义。andi $t0, $t0, 0x00FF的意图是"只保留低 8 位，其余清零"，这是一个掩码操作。如果立即数0x00FF被符号扩展，由于第 15 位是 0，扩展后还是0x000000FF，看起来没差；但如果写andi $t0, $t0, 0x8000，符号扩展会得到0xFFFF8000，高位全变 1，掩码语义就被破坏了。零扩展保证立即数的高位永远是 0，掩码就是纯粹的掩码，不会引入意外的 1。逻辑运算关心的是"位"，不是"数值大小"，所以零扩展才是对的。

4. 选错指令会怎样：三个真实的翻车场景

4.1 场景一：用 lb 读像素，负数让亮度计算出错

某图像处理的小 Demo 里，需要读取灰度图的每个像素做亮度累加求平均。像素值范围是 0 到 255，代码里图省事用了lb：

# 错误示范：用 lb 读无符号像素 loop: lb $t0, 0($s1) # 读一个像素 add $t2, $t2, $t0 # 累加到总和 addi $s1, $s1, 1 bne $s1, $s2, loop

问题出在像素值大于等于 128 的时候。比如读到0xC8（200），lb符号扩展后变成0xFFFFFFC8，也就是 -56。累加和不但没增加 200，反而减了 56。整张图越亮的地方，算出来的平均值反而越低，最后结果完全失真。

改成lbu就对了：

lbu $t0, 0($s1) # 正确：无符号像素用 lbu

这个坑的隐蔽之处在于：如果测试图恰好都很暗（像素值都小于 128），程序跑起来完全正常，一旦换成正常亮度的图就崩。所以测试用例一定要覆盖边界值，尤其是 0x80 和 0xFF 这两个点。

4.2 场景二：用 lbu 读有符号差分，负值被当成大正数

反过来也有翻车的时候。某音频处理代码里存的是相邻采样点的差分值，范围是 -128 到 127，用补码字节存储。读取时误用了lbu：

# 错误示范：有符号差分用了 lbu lbu $t0, 0($s1) # 差分 -1 存为 0xFF add $t2, $t2, $t0 # 期望减 1，实际加了 255

差分-1在内存里是0xFF，lbu零扩展后变成 255，累加时相当于加了 255 而不是减 1。波形重建出来完全变形，听起来像爆音。

这类 bug 的排查难点在于：单看某一次读取，值"看起来"是个合法的正数，不会触发任何异常，只有把整段数据连起来看趋势，才会发现数值系统性偏大。我的经验是，凡是处理"差分""增量""偏移量"这类可能为负的字节数据，一律先怀疑是不是该用lb。

4.3 场景三：模拟器里忘了覆盖高 24 位

这个坑属于自己写工具时踩的。前面提过，lb/lbu写回寄存器时是整个 32 位覆盖。有人在模拟器里图省事，只更新低 8 位：

# 错误示范：只改低 8 位，高位残留旧值 def exec_lb(regs, rt, value): regs[rt] = (regs[rt] & 0xFFFFFF00) | (value & 0xFF)

正确写法应该是完整覆盖：

# 正确：符号扩展后整体覆盖 def exec_lb(regs, rt, value): byte = value & 0xFF if byte & 0x80: # 最高位为 1 regs[rt] = byte | 0xFFFFFF00 # 符号扩展 else: regs[rt] = byte # 高位自然为 0 def exec_lbu(regs, rt, value): regs[rt] = value & 0xFF # 零扩展，高位清零

只改低位的写法在寄存器初值为 0 时碰巧能跑对，一旦寄存器里有残留数据就出错。这种"时对时错"的 bug 最难查，因为它的表现依赖于执行历史。写模拟器时，凡是涉及"写寄存器"的操作，都要问自己一句：这次写是覆盖全部 32 位，还是只改一部分？加载指令的答案是前者。

5. 手写一段代码把两种扩展跑给你看

5.1 完整可运行的验证程序

光看表格不够直观，直接上一段能在 MIPS 模拟器（如 MARS、QtSPIM 这类教学模拟器）里跑的代码，把lb和lbu的结果并排打出来对比：

.data buf: .byte 0xFF, 0x7F, 0x80, 0x01 .text main: la $s0, buf # s0 指向数据缓冲区 lb $t0, 0($s0) # 读 0xFF，符号扩展 lbu $t1, 0($s0) # 读 0xFF，零扩展 lb $t2, 1($s0) # 读 0x7F，符号扩展 lbu $t3, 1($s0) # 读 0x7F，零扩展 lb $t4, 2($s0) # 读 0x80，符号扩展 lbu $t5, 2($s0) # 读 0x80，零扩展 # 此时各寄存器预期值： # t0 = 0xFFFFFFFF (-1) t1 = 0x000000FF (255) # t2 = 0x0000007F (127) t3 = 0x0000007F (127) # t4 = 0xFFFFFF80 (-128) t5 = 0x00000080 (128) li $v0, 10 # 退出 syscall

跑完之后在寄存器窗口里逐个核对，你会发现几个规律：

• 字节值小于0x80（最高位为 0）时，lb和lbu结果完全相同，因为符号位是 0，符号扩展等价于零扩展。
• 字节值大于等于0x80时，两者才分道扬镳，lb得到负数，lbu得到正数。
• 0x80这个点最特殊：lb得到 -128（8 位有符号数的最小值），lbu得到 128。

5.2 用这段代码建立"边界直觉"

我建议你亲手把0x7F、0x80、0xFF这三个值都跑一遍，因为它们正好卡在符号位的分界线上：

• 0x7F= 二进制0111 1111，最高位 0，是 8 位有符号数能表示的最大正值 127。
• 0x80= 二进制1000 0000，最高位 1，是 8 位有符号数能表示的最小负值 -128。
• 0xFF= 二进制1111 1111，最高位 1，有符号解释是 -1，无符号解释是 255。

把这三个点记住，以后看到任何字节值，脑子里能立刻反应出"它用 lb 是多少、用 lbu 是多少"。这种直觉在调试时非常值钱——当你怀疑某个加载指令选错了，直接心算一下边界值，比翻手册快得多。

注意：不同模拟器对未初始化寄存器的初值处理可能不同，跑对比实验前最好先把目标寄存器清零（比如li $t0, 0），排除残留值的干扰，否则你看到的差异可能来自旧数据而不是扩展规则。

6. 写代码和写模拟器时的几条硬经验

6.1 选指令的判断流程可以固化成三步

在实际项目里，我总结了一个几乎不会出错的三步判断法，遇到字节加载就套一遍：

1. 问语义：这个字节在业务上可能是负数吗？可能为负（差分、温度、有符号采样）走第 2 步的"有符号"分支；只可能非负（字符、像素、标志、无符号计数）走"无符号"分支。
2. 有符号选lb，无符号选lbu，不要因为"lbu 看起来更安全"就一律用它，那会在有符号场景引入系统性偏差。
3. 验证边界：写测试时强制构造0x80和0xFF两个值，确认加载后的结果符合预期。这两个值能覆盖符号扩展和零扩展的全部分歧。

这套流程的价值在于它把"记指令"变成了"判断语义"，即使哪天换了别的指令集（比如 ARM 的LDRSB/LDRB），同样的思路照样能用。

6.2 汇编里做无符号比较，别用错分支指令

扩展选对了，还有第二个坑等着：比较。MIPS 的分支指令blt/ble/bgt/bge默认按有符号比较，如果你加载的是无符号字节，直接拿去做大小比较会出错。比如lbu读到的 200（0xC8）和 100 比较，有符号比较会把 200 当成负数，结果200 < 100反而成立。

无符号比较要用bltu/bleu/bgtu/bgeu这一组带 u 的指令。这个细节和lb/lbu是配套的：加载用无符号，比较也要用无符号，两边保持一致，语义才自洽。我见过有人加载用了lbu、比较却用了blt，结果在数据超过 127 时判断全反，排查时还以为是加载指令的问题，绕了一大圈。

6.3 模拟器实现里，扩展逻辑要抽成独立函数

如果你在写指令集模拟器，强烈建议把符号扩展和零扩展抽成两个独立的小函数，所有需要扩展的地方统一调用，而不是在每个指令的处理逻辑里各写一遍：

def sign_extend(value, bits): """把 bits 位的有符号数符号扩展成 32 位""" sign_bit = 1 << (bits - 1) return (value & (sign_bit - 1)) - (value & sign_bit) def zero_extend(value, bits): """把 bits 位的数零扩展成 32 位""" return value & ((1 << bits) - 1)

这么做的理由很实际：扩展逻辑一旦分散，改一处漏一处，lb改对了lh忘了改，addi又用了零扩展，bug 会像打地鼠一样冒出来。抽成函数后，lb调sign_extend(v, 8)，lh调sign_extend(v, 16)，addi调sign_extend(imm, 16)，andi调zero_extend(imm, 16)，一眼就能看出每个指令用了哪种扩展，审查代码时也方便对照规范逐条核对。

6.4 一个反直觉的提醒：addiu 的立即数仍然符号扩展

最后再强调一次这个高频误区，因为它太容易在面试和实际编码里坑人。addiu名字里的 "u" 表示Unsigned，但它的含义是"不触发溢出异常"（no overflow trap），而不是"立即数按无符号处理"。addiu的 16 位立即数依然做符号扩展。

也就是说，addiu $t0, $t0, 0xFFFF实际执行的是$t0 = $t0 + (-1)，而不是加 65535。如果你想要"加一个无符号的 16 位立即数"，得先用ori或lui把常数装进寄存器，再做寄存器加法。这个命名和行为的错位是 MIPS 历史遗留的设计，记住结论就行：看到 addiu，立即数照样符号扩展，别被字母 u 骗了。

把lb/lbu这一对吃透，其实就吃透了 MIPS 扩展规则的大半。剩下的lh/lhu、addi/andi、分支偏移，无非是同一套"符号位复制还是补零"的逻辑在不同位宽、不同指令上的重复。真正需要花心思的不是背规则，而是养成"先判断数据语义、再选扩展方式"的习惯——指令是死的，语义判断才是活的。我在实际调试里踩过的那些坑，几乎都能追溯到"没想清楚这个字节到底有没有符号"这一步。