2. 立即数优化：编码方式与高效选择策略

立即数，说白了就是指令里直接写死的那个数值。比如 MOV R0, #0x100 里的 0x100。很多新手觉得这玩意儿简单，不就是个数字嘛。但我在项目中踩过好几次坑，才发现立即数的门道比想象中深得多。

你想想看，CPU 执行指令时，立即数是跟指令编码一起从内存取回来的。如果编码方式不合理，或者选了个“大块头”立即数，轻则多占几个字节，重则让流水线多等好几个周期。今天我们就把它彻底聊透。

2.1 立即数的编码方式

不同架构对立即数的编码策略完全不同。我以最典型的 ARM 和 x86 为例，带你看看背后的设计哲学。

架构	立即数编码方式	典型限制	我的经验
ARM (32-bit)	8位基数 + 4位循环右移	只能表示有限数值	经常需要 MOV + ORR 拼凑
x86	变长编码 (1/2/4字节)	无特殊限制	但大立即数会撑爆指令缓存
RISC-V	12位有符号立即数	范围 [-2048, 2047]	超范围需 LUI + ADDI
ARM64	多种编码模式	支持移位、掩码模式	比 ARM32 灵活很多

拿 ARM32 来说，它的立即数编码是个经典设计——用 8 位表示数值，4 位表示循环右移的次数。这意味着不是所有 32 位整数都能直接编码。比如 0x1F0 可以，但 0x1F1 就不行。

2.2 如何选择高效的立即数

我个人习惯把立即数分成三类，每类的处理策略完全不同。

2.2.1 小立即数（0-255）

这类数值在大多数架构里都能直接编码。比如 ARM 的 MOV R0, #0x42，一条指令搞定，又快又省空间。

我的建议：能用 0-255 的数值，绝不用更大的。比如循环计数 256 次，我会改成 255 次加一次额外判断，或者用 0x100 配合移位。

2.2.2 可移位立即数

很多架构支持对立即数做移位。比如 ARM 的 MOV R0, #0xFF00 实际编码为 0xFF 左移 8 位。这类数值虽然看起来大，但编码效率很高。

2.2.3 大立即数（需要构造）

当数值无法直接编码时，就需要多条指令来构造。比如 ARM32 里加载 0x12345678：

; 低效方式：直接加载
LDR R0, =0x12345678  ; 这其实是个伪指令，会生成常量池访问

; 高效方式：拆分成可编码的立即数
MOV R0, #0x12000000
ORR R0, R0, #0x340000  ; 注意这里实际编码为 0x34 循环右移
ORR R0, R0, #0x5600
ORR R0, R0, #0x78

嗯，这里要注意。上面这个例子虽然用了 4 条指令，但比从常量池加载要快。因为常量池访问涉及内存读取，而指令流水线可以连续执行这些 MOV/ORR。

2.3 避免大立即数带来的性能开销

我曾经在一个音频解码项目里，发现某个关键循环的性能始终上不去。用 profiler 一查，罪魁祸首就是一条 LDR R0, =0x3FFF——编译器生成了常量池访问，每次循环都要多等 3 个周期。

从那以后，我总结了一套避坑指南：

1. 能用移位就别用常量池：比如 0x3FFF 可以写成 (1 << 14) - 1，用 MOV + SUB 实现。
2. 重复使用的立即数先加载到寄存器：如果同一个大立即数在循环里出现多次，提前加载到寄存器，循环里直接用。
3. 利用位掩码指令：ARM64 的 AND 支持多种掩码模式，很多看似复杂的立即数其实可以直接编码。

2.4 立即数优化的核心逻辑

下面这张图总结了我处理立即数时的决策流程：

2.5 实战中的常见陷阱

我整理了几个实际项目中遇到过的坑，你写代码时可以对照着检查：

• 陷阱一：用 0xFFFFFFFF 做掩码。其实 MVN R0, #0 就能生成全 1，比加载立即数快得多。
• 陷阱二：在循环里反复加载同一个立即数。提前加载到寄存器，循环体里直接用。
• 陷阱三：忽略编译器的常量合并能力。有时候 a + 1 和 a + 2 分开写，编译器反而能优化成一条 ADD 指令。