1. 从一次报错说起立即数为什么在 ARM 上是个结构性难题第一次在交叉汇编器里敲下mov r0, #0x12345678看到屏幕上甩出一句 invalid constant绝大多数人的第一反应是工具坏了。可换个写法mov r0, #0xFF立刻就过再换成mov r0, #0x100也没问题偏偏就是那个八位十六进制数不行。等你在反汇编器里看到x 0xFF00FF00这种一行 C 代码被展开成三条指令外加一次内存访问才会意识到这件事不是 bug而是 ARM 架构立即数机制从设计第一天就定下的规矩。所谓ARM 架构立即数机制说白了就是一条指令里怎么塞进一个常数这件事。CISC 体系里这不是问题指令可以变长想要 32 位常数就多给 32 位编码空间。ARM 走的是定长指令路线A32 每条指令固定 32 位这 32 位里要装条件码、操作码、目标寄存器、源寄存器剩下的空间给立即数就非常紧张。于是做架构的那批人想了个折中不直接存 32 位常数只存一个 8 位的种子再存一个旋转量靠硬件里的桶形移位器把种子转到位。这套机制能覆盖相当一部分常用常数但覆盖不全剩下的就得靠多条指令拼出来。这篇文章想解决的问题很具体让你在看到任意一个 32 位或 64 位常数时能在几秒钟内判断它能不能塞进一条指令如果不能知道该用哪种方式绕过去以及每种方式在代码尺寸、执行周期、缓存行为上各自付出什么代价。写裸机启动代码的、做性能优化看反汇编的、写 JIT 动态生成机器码的、做逆向和漏洞分析的还有把原有代码往 ARM 平台上移植的都会反复撞上这堵墙。我见过太多人在这里卡住最后靠多试几种写法直到汇编器不报错这种办法蒙混过去代码能跑但说不清为什么一旦换编译器版本或者换架构档位就又崩了。真正把这件事吃透需要同时理解三样东西指令编码的位域约束、汇编器/编译器的展开策略、以及目标架构版本之间的差异。这三者缺一个你对立即数的判断就是不准的。2. ARM 状态下的 12 位立即数8 位常数加 4 位旋转的真实来历2.1 数据处理指令的位域分配A32 状态下最常见的那些数据处理指令——MOV、ADD、SUB、AND、ORR、EOR、CMP、TST——第二个操作数叫 Operand2它有三种形态寄存器、寄存器加移位、立即数。走立即数形态时指令第 25 位置 1剩下的 12 位就是全部家当。这 12 位被切成两半位段宽度含义[11:8]4 位旋转量字段 rotate实际旋转位数 rotate × 2[7:0]8 位立即数种子 imm8计算规则只有一句话最终常数 imm8 循环右移 (rotate × 2) 位。注意是循环右移不是逻辑右移移出去的低位会从最高位补回来信息一点不丢。拿几个具体值走一遍。0xFF000000怎么来取 imm8 0xFFrotate 4右移 8 位低 8 位的 0xFF 转到最高 8 位得到 0xFF000000。0x0000FF00呢imm8 0xFFrotate 12右移 24 位0xFF 落到 bit8 到 bit15正好是 0x0000FF00。再看0xC0000003这个值乍看很怪但把 0x0F 右移 2 位低两位的11转到 bit30 和 bit31原来 bit2 到 bit5 的1111落到 bit0 到 bit3拼出来正是 0xC0000003所以 rotate 1imm8 0x0F。这里有个容易忽略的点rotate 字段是 4 位理论上能表达 0 到 15但实际有效旋转量是 0、2、4……30奇数旋转量根本表示不了。这就是为什么0x104合法0x41 右移 30 位等价于左移 2 位而0x102不合法——后者的两个 1 分别在 bit1 和 bit8需要一个奇数偏移的 8 位窗口才能框住硬件给不了。2.2 为什么是循环右移而不是普通左移这是我最开始学的时候没想明白的地方。用左移不是也能把低位的小常数搬到高位吗能但左移会丢位。比如把 0xFF 左移 24 位结果确实是 0xFF000000可如果我想表示 0xFF0000FF也就是高 8 位和低 8 位同时为 1左移就彻底没戏了因为一次操作只能朝一个方向走。循环右移的价值在于它是个闭环操作。0xFF 右移 24 位低 8 位跑到最高 8 位而右移过程中从最高位转回低位的部分在 8 位种子全在低位的场景下是零所以能得到 0x0000FF00 这种中间位置的取值。换句话说一个 8 位种子配合 16 种旋转量能在 32 位空间里布下 16 个均匀分布步长 2的窗口位置每一步是 8 位宽的连续区间。硬件实现上也不额外花钱——数据通路上本来就有桶形移位器MOV立即数直接复用这条通路几乎零成本。2.3 84 与 75 的编码空间之争这里有个很多人不知道的细节12 位怎么切其实有两种选择。方案一是 8 位常数加 4 位旋转量旋转量乘 2方案二是 7 位常数加 5 位旋转量旋转量不乘 2。两者的编码总数完全一样——方案一是 256 × 16 4096方案二是 128 × 32 4096。既然数量相同选哪个就看哪个覆盖的常用值更多。答案藏在常用常数长什么样里。小整数、0xFF 这类字节掩码、0xFF00 这类对齐掩码占据了实际代码里绝大多数立即数出现次数。8 位种子刚好能完整表示 0 到 255而 7 位种子只能到 127连常见的0xFF都装不下只能靠旋转凑非常别扭。另一方面大常数通常也是字节对齐的——0x12345678 这种真正的随机数很少直接出现在指令里0xFF00FF00、0x80000000这些带明显规律的值才常见而它们的非零位窗口起点基本都是偶数位对齐的。注意这个取舍直接决定了 ARM 上能一条指令加载的常数集合边界。你判断一个值合不合法本质上是在问它的所有非零位能不能被某个从偶数位开始的 8 位窗口全部框住。3. 立即数合法性判定手算、代码和一张对照表3.1 三秒钟手判法我不推荐任何人去背哪些数合法的清单4096 个编码对应的不同值有好几千个背不下来也没必要。真正实用的是一套可以口算的判定流程熟练之后看一个十六进制值三秒钟就能出结论。第一步把值写成二进制只看 1 的位置忽略 0。第二步找出这些 1 在 32 位环上能形成的最短连续段——注意是环bit31 和 bit0 是相邻的所以 0xC0000003 里的 bit30、bit31、bit0、bit1 其实是一个连续段。第三步看两件事这个段的宽度是不是不超过 8 位这个段的起始位是不是偶数位。两个都满足就合法否则就是不合法。拿0x8100试一下。二进制是1000 0001 0000 00001 在 bit8 和 bit15连续段宽度 8 位起点是 bit8偶数合法。编码方式是把 0x81 塞进低 8 位然后右移 24 位rotate 12低 8 位的1000 0001转到 bit8 到 bit15高 8 位的 0x00 转到低位得到 0x8100。再拿0x101试。1 在 bit0 和 bit8连续段宽度 9 位从 bit0 数到 bit8 共 9 个位置超了不合法。这就是为什么汇编器会报错。再看一个反直觉的0xFFFFFF00。你可能会想这不就是 0xFF 右移 8 位吗不对。0xFF 右移 8 位是 0xFF000000把 0x000000FF 整个搬到最高字节去了。0xFFFFFF00 是 24 个连续的 1宽度远超 8 位怎么会合法查一下发现它确实不在直接 MOV的合法集合里。但实际写代码时mov r0, #0xFFFFFF00经常能过这是因为汇编器自动把它转成了MVN r0, #0x000000FF——取反之后只有 8 位当然合法。3.2 用十几行代码做精确判定手算适合验证单个值批量检查或者写工具的时候还是得靠代码。判定逻辑的核心就是把原值左旋若干位看能不能落进低 8 位def check_arm_imm(v): v 0xFFFFFFFF for rot in range(0, 32, 2): if rot 0: w v else: w ((v rot) | (v (32 - rot))) 0xFFFFFFFF if w 0xFF: # 反向推出编码字段 return True, w, rot // 2 return False, None, None for x in (0xFF, 0x104, 0x1000, 0xFF000000, 0x8100, 0x101, 0x1FE, 0xFFFFFF00): ok, seed, rot check_arm_imm(x) print(hex(x), ok, hex(seed) if seed is not None else -, rot)打印结果会清楚地告诉你0x1FE 不合法9 位宽0xFFFFFF00 不合法24 位宽而 0x104 的编码是 seed 0x41、rotate 15。这段代码有个坑要提醒rot为 0 的时候不能直接写(v 0) | (v 32)Python 里右移 32 位虽然不会报错但逻辑上是无效操作语义容易搞混必须单独分支处理。C 语言里更危险移位量等于位宽是未定义行为实际跑出来的结果取决于编译器。如果你想得到这条指令一定合法的结论还得考虑MVN的反向情况。判定的完整版应该是check_arm_imm(v)为真或者check_arm_imm(~v 0xFFFFFFFF)为真后者会被汇编器转成MVN。3.3 常见值的合法性与典型误判下面这张表是我从实际项目里整理出来的基本覆盖了日常遇到的绝大多数场景立即数是否可单条加载编码方式 / 原因0xFF合法imm8 0xFFrotate 00x100合法imm8 0x01rotate 10右移 20 位0x104合法imm8 0x41rotate 15右移 30 位0x8100合法imm8 0x81rotate 120xFF000000合法imm8 0xFFrotate 40x80000000合法imm8 0x02rotate 150xC0000003合法imm8 0x0Frotate 10x101不合法两个 1 跨越 9 位超出 8 位窗口0x1FE不合法9 位连续 10xFFFFFF00不合法直接 MOV需改用 MVN 0x000000FF0xFFFFFF不合法24 位连续 1MVN 也救不了0x12345678不合法非零位散布全字0x00FF00FF不合法两段 1 相隔 8 位窗口框不住最后一行特别值得说。很多人觉得 0x00FF00FF 这种有规律的值应该能加载实际不行。它的非零位在 bit0 到 bit7 和 bit16 到 bit23两段之间隔着 8 位 0任何 8 位窗口都只能罩住其中一段。在 AArch64 的位模式立即数里它是合法的但因为指令宽度和编码方式不同那是另一套规则不能混用。4. 绕开 12 位限制的四条工程路线4.1 MOVW/MOVT确定性强但吃指令槽从 ARMv6T2 开始Thumb-2 体系同时引入架构里多了两条专门处理 16 位立即数的指令。MOVW Rd, #imm16把低 16 位装进寄存器高 16 位清零MOVT Rd, #imm16把 16 位值装进高半部分低半部分保持不变。两条配合任何 32 位常数都能用两条指令搞定movw r0, #0x5678 movt r0, #0x1234 r0 0x12345678这个方案的优点是完全可预测。没有内存访问不依赖数据池位置不产生额外的 I-Cache 压力指令流是纯粹顺序的流水线上不会因为 load-use 冒险停顿。缺点也很明确固定占两条指令、8 字节而且必须成对出现编译器很难把两条指令拆开调度。如果这个常数要在一段循环里反复加载而寄存器又紧张不得不每次重载累加起来就很可观了。我在做引导程序的启动代码时基本只用这一种方式。原因是那个阶段内存子系统还没完全初始化数据池里的常量可能读不出来MOVW/MOVT只用通用寄存器最稳妥。4.2 LDR 伪指令与文字池灵活但有代价写ldr r0, 0x12345678的时候你写的不是一条真实指令而是一个给汇编器的请求。汇编器会把这个常数扔进一个叫文字池literal pool的数据区然后生成一条相对于 PC 的加载指令从池里把它取出来ldr r0, 0x12345678 实际生成 ldr r0, [pc, #offset] ... .ltorg 强制在此处转储文字池优点很诱人任何 32 位值都能处理不需要预先判断合法性同一个常数在同一个池里只存一份多次加载共享同一份数据生成的是单条指令代码尺寸上比MOVW/MOVT更省。现代编译器在-O2以上基本都优先用这条路。代价藏在三个地方。第一是多了内存访问。虽然池通常紧跟在代码后面命中缓存的概率很高但在冷启动、频繁切换工作集的场景下就是额外的 cache miss。第二是池的位置约束。PC 相对加载的偏移范围是有限的A32 下大约是 ±4KB代码一长就必须用.ltorg定期插入新池或者在函数返回前手动放置。插入位置放错了会直接编译报错 literal pool out of range。第三是位置无关代码里的复杂性池本身的地址必须能通过 PC 相对寻址拿到某些链接场景下要特殊处理。提示.ltorg不是随便加的。它会把当前所有未转储的常量一次性写出来插在函数中间会打乱指令流插在函数末尾则可能因为跳转指令的关系永远执行不到——数据区不能被执行到所以通常要放在无条件跳转之后。4.3 MVN、移位和算术构造编译器最爱用的手法回到那个 0xFFFFFF00 的例子。汇编器不会用MOVW/MOVT也不会用文字池它直接生成mvn r0, #0xFF。MVN是按位取反后搬移它的操作数编码规则和MOV完全一样所以只要取反后的值落在 8 位窗口内一条指令就够了。这直接把可表示集合扩大了一倍等于 4096 个正向编码加上 4096 个反向编码去重之后大概六七千个不同值。同样的思路还能叠加移位。想加载 0x1F00000可以先mov r0, #0x1F再lsl r0, r0, #20虽然占两条指令但都是寄存器操作不碰内存。编译器在做常量合成constant synthesis时会有一个成本模型把所有可行方案——单条MOV、单条MVN、MOVW/MOVT、MOV 移位、MOVORR、文字池加载——各自算出指令数和周期数挑最便宜的。这个选择过程在不同编译器版本、不同-mcpu参数下结果可能不一样所以同一段 C 代码在两个工具链上反汇编出来的东西经常长得完全不同。我自己做手工优化时的经验是小常数优先想 MVN中等常数优先想移位大常数老老实实用文字池。判断中等的标准很简单如果这个值的非零位集中在一段不超过 8 位的区间里只是起点不对那就用移位修正起点通常两条指令能搞定。4.4 内联汇编与约束符的正确写法在 C 代码里嵌汇编的时候立即数的合法性判断会变得很微妙。约束符 I 就是告诉编译器这个操作数必须是合法的 ARM 立即数编译器会负责检查如果你传进去一个不合法的值编译期就会报错。反过来如果你写的是裸的mov %0, #%1这种字符串拼接式内联汇编编译器根本不知道你在干什么非法值会一路传到汇编器才报错错误信息的位置指向往往很不友好。// 正确交给编译器判断不合法时它会自己拆成多条指令 static inline void set_mask(unsigned int v) { __asm__ volatile(mov r0, %0 :: I(0xFF)); }实际项目里我倾向于把这类操作封装成一个宏宏内部用约束符约束让编译期就把问题暴露出来而不是等到链接阶段看到一堆奇怪的符号。5. Thumb 与 Thumb-2立即数编码的两次调整5.1 16 位 Thumb 的 8 位紧箍咒切到 Thumb 模式指令宽度砍到 16 位留给立即数的空间就更少了。16 位版本的MOV只能带一个 8 位无符号立即数取值范围 0 到 255没有任何旋转。ADD和SUB稍微好一点有两种形态3 位立即数0 到 7指令更短更省和 8 位立即数0 到 255。这个限制在实际开发里非常疼。GPIO寄存器偏移动辄 0x400、0x1000Thumb 16 位指令一条都带不动必须靠多条指令拼。早年做 Cortex-M 系列裸机开发的人都记得往寄存器写一个 0x40010000 这样的地址汇编出来是三四条指令先mov低位再lsl或add拼高位。代码密度优势被这些拼接指令吃掉一大半。也正因为如此Thumb-2 的出现不只是把指令拉宽到 32 位那么简单它同时解决了立即数表达力的问题。5.2 Thumb-2 的 modified immediate 好在哪里Thumb-2 里 32 位数据处理指令的立即数编码是 12 位字段叫i:imm3:imm8分散在指令的三个位置bit26 的i、bit14 到 bit12 的imm3、bit7 到 bit0 的imm8。这 12 位怎么解释取决于最高两位模式一当imm12[11:10] 0b00时低 8 位是一个字节值高 2 位在 bit9 到 bit8决定这个字节被复制到 32 位的什么位置imm12[9:8]结果000x000000XY010x0000XY00100x00XY00XY110xXYXYXYXY这个复制能力是 A32 完全没有的。想想0xXYXYXYXY这种模式在 A32 里除非 XY 是 0x00 或 0xFF否则想都别想一条指令搞定而在 Thumb-2 里一条就够。模式二当最高两位不全为 0 时取0b1拼上imm12[6:0]组成 8 位种子旋转量取imm12[11:7]这 5 位取值范围 0 到 31不限于偶数。这一点比 A32 强意味着那些起点在奇数位的 8 位窗口现在也能表示了比如 0x102 这种在 A32 里绝对不合法的值Thumb-2 可以一条指令加载。5.3 三种编码方式的横向对比把 A32、16 位 Thumb、Thumb-2 三者的能力摊开对比差异一目了然编码方式指令位宽立即数字段可表示的典型值A32 数据处理328 位种子 4 位偶数旋转0xFF000000、0x104、0x8100Thumb 16 位168 位无旋转0 到 255Thumb-2 数据处理3212 位i:imm3:imm8上述全部外加 0xXYXYXYXY 和奇数起点窗口实际工程里的经验是开了 Thumb-2 之后因为立即数不合法而产生的额外指令会显著减少但又没有完全消失。像 0x12345678 这种真正的随机数任何模式都装不下还是得靠MOVW/MOVT或者文字池。跨架构移植的时候同一个汇编片段在 ARM 状态能过、切到 Thumb 状态就报错绝大多数情况就是撞在这个位宽差异上。6. AArch64 的重新设计位模式立即数与 12 位算术立即数6.1 ADD/SUB 的 12 位加左移 12到了 64 位时代做架构的人干脆把问题拆成两类分别用不同的编码方式解决。第一类是算术立即数用在ADD、SUB、CMP、CMN上编码是 12 位 imm12 加一个 1 位的sh标志。sh 0时直接取值 0 到 4095sh 1时表示 imm12 左移 12 位得到 4096 到 16777215 之间步长为 4096 的值。这套规则简单到不需要任何种子 旋转的心智负担。你只要记住两个区间小整数直接写大整数按 4KB 页对齐。内存访问指令的偏移量也是同样的编码这也是为什么 AArch64 的加载偏移上限是 4095 字节或者按 8 字节缩放的 32KB 左右和这个设计一脉相承。add x0, x1, #100 // 0 到 4095 区间 add x0, x1, #0x1000, lsl #12 // 等价于加 0x10000006.2 逻辑立即数的 bitmask 编码怎么判第二类是逻辑立即数用在AND、ORR、EOR、ANDS以及 64 位版本的MOV别名MOVZ之外的那个上。这部分用的是 13 位的N:immr:imms编码表达能力比 A32 强得多但判定逻辑也复杂得多。不用管具体的解码公式实用的判定方法是三条找到这个值在 64 位环上的最小重复单元单元长度必须是 1、2、4、8、16、32、64 这些 2 的幂这个单元内必须是循环连续的 1也就是从某一位开始的一串 1允许跨越单元边界环绕整个 64 位值必须是这个单元的不间断重复。举几个例子就清楚了。0xFF00FF00FF00FF00的最小重复单元是 0xFF长度 8 位单元内是 8 个连续 1整个值就是 0xFF 重复 8 次合法。0x5555555555555555的单元是 2 位单元内是01从 bit0 看只有一个 1循环看是连续的合法。0x00000000000001FF的单元长度必须是 64 位因为低 9 位是 1、高位全 0任何更小的单元重复都会产生非零高位64 位环上从 bit0 到 bit8 是连续 9 个 1也算循环连续合法——这个值在 A32 里是绝对不行的正好体现了两代架构的差异。反面例子是0x12345678最小重复单元只能是 32 位0x12345678 本身单元内 1 的分布散乱不构成循环连续段非法。再比如0x0000000081000000两个 1 分别位于 bit24 和 bit31中间隔了 6 位 064 位环上从 bit31 绕到 bit24 又是 7 位 0两头都不连续非法。如果你要写工具做判定思路和前面的 Python 代码类似只不过循环单元长度和循环连续的判断要复杂一些def check_a64_logic_imm(v): v 0xFFFFFFFFFFFFFFFF for esize in (2, 4, 8, 16, 32, 64): mask (1 esize) - 1 unit v mask # 检查整个值是否是 unit 的重复 if v ! unit * (0xFFFFFFFFFFFFFFFF // mask): continue # 检查 unit 内部是否为循环连续的一段 1 s bin(unit)[2:].zfill(esize) doubled s s ones unit.bit_count() if ones 0: return True if s in (0 * (esize - ones) 1 * ones, 1 * ones 0 * (esize - ones)): return True # 更通用的写法检查 doubled 中是否出现连续 ones 个 1 if 1 * ones in doubled: return True return False
1. 从一次报错说起立即数为什么在 ARM 上是个结构性难题第一次在交叉汇编器里敲下mov r0, #0x12345678看到屏幕上甩出一句 invalid constant绝大多数人的第一反应是工具坏了。可换个写法mov r0, #0xFF立刻就过再换成mov r0, #0x100也没问题偏偏就是那个八位十六进制数不行。等你在反汇编器里看到x 0xFF00FF00这种一行 C 代码被展开成三条指令外加一次内存访问才会意识到这件事不是 bug而是 ARM 架构立即数机制从设计第一天就定下的规矩。所谓ARM 架构立即数机制说白了就是一条指令里怎么塞进一个常数这件事。CISC 体系里这不是问题指令可以变长想要 32 位常数就多给 32 位编码空间。ARM 走的是定长指令路线A32 每条指令固定 32 位这 32 位里要装条件码、操作码、目标寄存器、源寄存器剩下的空间给立即数就非常紧张。于是做架构的那批人想了个折中不直接存 32 位常数只存一个 8 位的种子再存一个旋转量靠硬件里的桶形移位器把种子转到位。这套机制能覆盖相当一部分常用常数但覆盖不全剩下的就得靠多条指令拼出来。这篇文章想解决的问题很具体让你在看到任意一个 32 位或 64 位常数时能在几秒钟内判断它能不能塞进一条指令如果不能知道该用哪种方式绕过去以及每种方式在代码尺寸、执行周期、缓存行为上各自付出什么代价。写裸机启动代码的、做性能优化看反汇编的、写 JIT 动态生成机器码的、做逆向和漏洞分析的还有把原有代码往 ARM 平台上移植的都会反复撞上这堵墙。我见过太多人在这里卡住最后靠多试几种写法直到汇编器不报错这种办法蒙混过去代码能跑但说不清为什么一旦换编译器版本或者换架构档位就又崩了。真正把这件事吃透需要同时理解三样东西指令编码的位域约束、汇编器/编译器的展开策略、以及目标架构版本之间的差异。这三者缺一个你对立即数的判断就是不准的。2. ARM 状态下的 12 位立即数8 位常数加 4 位旋转的真实来历2.1 数据处理指令的位域分配A32 状态下最常见的那些数据处理指令——MOV、ADD、SUB、AND、ORR、EOR、CMP、TST——第二个操作数叫 Operand2它有三种形态寄存器、寄存器加移位、立即数。走立即数形态时指令第 25 位置 1剩下的 12 位就是全部家当。这 12 位被切成两半位段宽度含义[11:8]4 位旋转量字段 rotate实际旋转位数 rotate × 2[7:0]8 位立即数种子 imm8计算规则只有一句话最终常数 imm8 循环右移 (rotate × 2) 位。注意是循环右移不是逻辑右移移出去的低位会从最高位补回来信息一点不丢。拿几个具体值走一遍。0xFF000000怎么来取 imm8 0xFFrotate 4右移 8 位低 8 位的 0xFF 转到最高 8 位得到 0xFF000000。0x0000FF00呢imm8 0xFFrotate 12右移 24 位0xFF 落到 bit8 到 bit15正好是 0x0000FF00。再看0xC0000003这个值乍看很怪但把 0x0F 右移 2 位低两位的11转到 bit30 和 bit31原来 bit2 到 bit5 的1111落到 bit0 到 bit3拼出来正是 0xC0000003所以 rotate 1imm8 0x0F。这里有个容易忽略的点rotate 字段是 4 位理论上能表达 0 到 15但实际有效旋转量是 0、2、4……30奇数旋转量根本表示不了。这就是为什么0x104合法0x41 右移 30 位等价于左移 2 位而0x102不合法——后者的两个 1 分别在 bit1 和 bit8需要一个奇数偏移的 8 位窗口才能框住硬件给不了。2.2 为什么是循环右移而不是普通左移这是我最开始学的时候没想明白的地方。用左移不是也能把低位的小常数搬到高位吗能但左移会丢位。比如把 0xFF 左移 24 位结果确实是 0xFF000000可如果我想表示 0xFF0000FF也就是高 8 位和低 8 位同时为 1左移就彻底没戏了因为一次操作只能朝一个方向走。循环右移的价值在于它是个闭环操作。0xFF 右移 24 位低 8 位跑到最高 8 位而右移过程中从最高位转回低位的部分在 8 位种子全在低位的场景下是零所以能得到 0x0000FF00 这种中间位置的取值。换句话说一个 8 位种子配合 16 种旋转量能在 32 位空间里布下 16 个均匀分布步长 2的窗口位置每一步是 8 位宽的连续区间。硬件实现上也不额外花钱——数据通路上本来就有桶形移位器MOV立即数直接复用这条通路几乎零成本。2.3 84 与 75 的编码空间之争这里有个很多人不知道的细节12 位怎么切其实有两种选择。方案一是 8 位常数加 4 位旋转量旋转量乘 2方案二是 7 位常数加 5 位旋转量旋转量不乘 2。两者的编码总数完全一样——方案一是 256 × 16 4096方案二是 128 × 32 4096。既然数量相同选哪个就看哪个覆盖的常用值更多。答案藏在常用常数长什么样里。小整数、0xFF 这类字节掩码、0xFF00 这类对齐掩码占据了实际代码里绝大多数立即数出现次数。8 位种子刚好能完整表示 0 到 255而 7 位种子只能到 127连常见的0xFF都装不下只能靠旋转凑非常别扭。另一方面大常数通常也是字节对齐的——0x12345678 这种真正的随机数很少直接出现在指令里0xFF00FF00、0x80000000这些带明显规律的值才常见而它们的非零位窗口起点基本都是偶数位对齐的。注意这个取舍直接决定了 ARM 上能一条指令加载的常数集合边界。你判断一个值合不合法本质上是在问它的所有非零位能不能被某个从偶数位开始的 8 位窗口全部框住。3. 立即数合法性判定手算、代码和一张对照表3.1 三秒钟手判法我不推荐任何人去背哪些数合法的清单4096 个编码对应的不同值有好几千个背不下来也没必要。真正实用的是一套可以口算的判定流程熟练之后看一个十六进制值三秒钟就能出结论。第一步把值写成二进制只看 1 的位置忽略 0。第二步找出这些 1 在 32 位环上能形成的最短连续段——注意是环bit31 和 bit0 是相邻的所以 0xC0000003 里的 bit30、bit31、bit0、bit1 其实是一个连续段。第三步看两件事这个段的宽度是不是不超过 8 位这个段的起始位是不是偶数位。两个都满足就合法否则就是不合法。拿0x8100试一下。二进制是1000 0001 0000 00001 在 bit8 和 bit15连续段宽度 8 位起点是 bit8偶数合法。编码方式是把 0x81 塞进低 8 位然后右移 24 位rotate 12低 8 位的1000 0001转到 bit8 到 bit15高 8 位的 0x00 转到低位得到 0x8100。再拿0x101试。1 在 bit0 和 bit8连续段宽度 9 位从 bit0 数到 bit8 共 9 个位置超了不合法。这就是为什么汇编器会报错。再看一个反直觉的0xFFFFFF00。你可能会想这不就是 0xFF 右移 8 位吗不对。0xFF 右移 8 位是 0xFF000000把 0x000000FF 整个搬到最高字节去了。0xFFFFFF00 是 24 个连续的 1宽度远超 8 位怎么会合法查一下发现它确实不在直接 MOV的合法集合里。但实际写代码时mov r0, #0xFFFFFF00经常能过这是因为汇编器自动把它转成了MVN r0, #0x000000FF——取反之后只有 8 位当然合法。3.2 用十几行代码做精确判定手算适合验证单个值批量检查或者写工具的时候还是得靠代码。判定逻辑的核心就是把原值左旋若干位看能不能落进低 8 位def check_arm_imm(v): v 0xFFFFFFFF for rot in range(0, 32, 2): if rot 0: w v else: w ((v rot) | (v (32 - rot))) 0xFFFFFFFF if w 0xFF: # 反向推出编码字段 return True, w, rot // 2 return False, None, None for x in (0xFF, 0x104, 0x1000, 0xFF000000, 0x8100, 0x101, 0x1FE, 0xFFFFFF00): ok, seed, rot check_arm_imm(x) print(hex(x), ok, hex(seed) if seed is not None else -, rot)打印结果会清楚地告诉你0x1FE 不合法9 位宽0xFFFFFF00 不合法24 位宽而 0x104 的编码是 seed 0x41、rotate 15。这段代码有个坑要提醒rot为 0 的时候不能直接写(v 0) | (v 32)Python 里右移 32 位虽然不会报错但逻辑上是无效操作语义容易搞混必须单独分支处理。C 语言里更危险移位量等于位宽是未定义行为实际跑出来的结果取决于编译器。如果你想得到这条指令一定合法的结论还得考虑MVN的反向情况。判定的完整版应该是check_arm_imm(v)为真或者check_arm_imm(~v 0xFFFFFFFF)为真后者会被汇编器转成MVN。3.3 常见值的合法性与典型误判下面这张表是我从实际项目里整理出来的基本覆盖了日常遇到的绝大多数场景立即数是否可单条加载编码方式 / 原因0xFF合法imm8 0xFFrotate 00x100合法imm8 0x01rotate 10右移 20 位0x104合法imm8 0x41rotate 15右移 30 位0x8100合法imm8 0x81rotate 120xFF000000合法imm8 0xFFrotate 40x80000000合法imm8 0x02rotate 150xC0000003合法imm8 0x0Frotate 10x101不合法两个 1 跨越 9 位超出 8 位窗口0x1FE不合法9 位连续 10xFFFFFF00不合法直接 MOV需改用 MVN 0x000000FF0xFFFFFF不合法24 位连续 1MVN 也救不了0x12345678不合法非零位散布全字0x00FF00FF不合法两段 1 相隔 8 位窗口框不住最后一行特别值得说。很多人觉得 0x00FF00FF 这种有规律的值应该能加载实际不行。它的非零位在 bit0 到 bit7 和 bit16 到 bit23两段之间隔着 8 位 0任何 8 位窗口都只能罩住其中一段。在 AArch64 的位模式立即数里它是合法的但因为指令宽度和编码方式不同那是另一套规则不能混用。4. 绕开 12 位限制的四条工程路线4.1 MOVW/MOVT确定性强但吃指令槽从 ARMv6T2 开始Thumb-2 体系同时引入架构里多了两条专门处理 16 位立即数的指令。MOVW Rd, #imm16把低 16 位装进寄存器高 16 位清零MOVT Rd, #imm16把 16 位值装进高半部分低半部分保持不变。两条配合任何 32 位常数都能用两条指令搞定movw r0, #0x5678 movt r0, #0x1234 r0 0x12345678这个方案的优点是完全可预测。没有内存访问不依赖数据池位置不产生额外的 I-Cache 压力指令流是纯粹顺序的流水线上不会因为 load-use 冒险停顿。缺点也很明确固定占两条指令、8 字节而且必须成对出现编译器很难把两条指令拆开调度。如果这个常数要在一段循环里反复加载而寄存器又紧张不得不每次重载累加起来就很可观了。我在做引导程序的启动代码时基本只用这一种方式。原因是那个阶段内存子系统还没完全初始化数据池里的常量可能读不出来MOVW/MOVT只用通用寄存器最稳妥。4.2 LDR 伪指令与文字池灵活但有代价写ldr r0, 0x12345678的时候你写的不是一条真实指令而是一个给汇编器的请求。汇编器会把这个常数扔进一个叫文字池literal pool的数据区然后生成一条相对于 PC 的加载指令从池里把它取出来ldr r0, 0x12345678 实际生成 ldr r0, [pc, #offset] ... .ltorg 强制在此处转储文字池优点很诱人任何 32 位值都能处理不需要预先判断合法性同一个常数在同一个池里只存一份多次加载共享同一份数据生成的是单条指令代码尺寸上比MOVW/MOVT更省。现代编译器在-O2以上基本都优先用这条路。代价藏在三个地方。第一是多了内存访问。虽然池通常紧跟在代码后面命中缓存的概率很高但在冷启动、频繁切换工作集的场景下就是额外的 cache miss。第二是池的位置约束。PC 相对加载的偏移范围是有限的A32 下大约是 ±4KB代码一长就必须用.ltorg定期插入新池或者在函数返回前手动放置。插入位置放错了会直接编译报错 literal pool out of range。第三是位置无关代码里的复杂性池本身的地址必须能通过 PC 相对寻址拿到某些链接场景下要特殊处理。提示.ltorg不是随便加的。它会把当前所有未转储的常量一次性写出来插在函数中间会打乱指令流插在函数末尾则可能因为跳转指令的关系永远执行不到——数据区不能被执行到所以通常要放在无条件跳转之后。4.3 MVN、移位和算术构造编译器最爱用的手法回到那个 0xFFFFFF00 的例子。汇编器不会用MOVW/MOVT也不会用文字池它直接生成mvn r0, #0xFF。MVN是按位取反后搬移它的操作数编码规则和MOV完全一样所以只要取反后的值落在 8 位窗口内一条指令就够了。这直接把可表示集合扩大了一倍等于 4096 个正向编码加上 4096 个反向编码去重之后大概六七千个不同值。同样的思路还能叠加移位。想加载 0x1F00000可以先mov r0, #0x1F再lsl r0, r0, #20虽然占两条指令但都是寄存器操作不碰内存。编译器在做常量合成constant synthesis时会有一个成本模型把所有可行方案——单条MOV、单条MVN、MOVW/MOVT、MOV 移位、MOVORR、文字池加载——各自算出指令数和周期数挑最便宜的。这个选择过程在不同编译器版本、不同-mcpu参数下结果可能不一样所以同一段 C 代码在两个工具链上反汇编出来的东西经常长得完全不同。我自己做手工优化时的经验是小常数优先想 MVN中等常数优先想移位大常数老老实实用文字池。判断中等的标准很简单如果这个值的非零位集中在一段不超过 8 位的区间里只是起点不对那就用移位修正起点通常两条指令能搞定。4.4 内联汇编与约束符的正确写法在 C 代码里嵌汇编的时候立即数的合法性判断会变得很微妙。约束符 I 就是告诉编译器这个操作数必须是合法的 ARM 立即数编译器会负责检查如果你传进去一个不合法的值编译期就会报错。反过来如果你写的是裸的mov %0, #%1这种字符串拼接式内联汇编编译器根本不知道你在干什么非法值会一路传到汇编器才报错错误信息的位置指向往往很不友好。// 正确交给编译器判断不合法时它会自己拆成多条指令 static inline void set_mask(unsigned int v) { __asm__ volatile(mov r0, %0 :: I(0xFF)); }实际项目里我倾向于把这类操作封装成一个宏宏内部用约束符约束让编译期就把问题暴露出来而不是等到链接阶段看到一堆奇怪的符号。5. Thumb 与 Thumb-2立即数编码的两次调整5.1 16 位 Thumb 的 8 位紧箍咒切到 Thumb 模式指令宽度砍到 16 位留给立即数的空间就更少了。16 位版本的MOV只能带一个 8 位无符号立即数取值范围 0 到 255没有任何旋转。ADD和SUB稍微好一点有两种形态3 位立即数0 到 7指令更短更省和 8 位立即数0 到 255。这个限制在实际开发里非常疼。GPIO寄存器偏移动辄 0x400、0x1000Thumb 16 位指令一条都带不动必须靠多条指令拼。早年做 Cortex-M 系列裸机开发的人都记得往寄存器写一个 0x40010000 这样的地址汇编出来是三四条指令先mov低位再lsl或add拼高位。代码密度优势被这些拼接指令吃掉一大半。也正因为如此Thumb-2 的出现不只是把指令拉宽到 32 位那么简单它同时解决了立即数表达力的问题。5.2 Thumb-2 的 modified immediate 好在哪里Thumb-2 里 32 位数据处理指令的立即数编码是 12 位字段叫i:imm3:imm8分散在指令的三个位置bit26 的i、bit14 到 bit12 的imm3、bit7 到 bit0 的imm8。这 12 位怎么解释取决于最高两位模式一当imm12[11:10] 0b00时低 8 位是一个字节值高 2 位在 bit9 到 bit8决定这个字节被复制到 32 位的什么位置imm12[9:8]结果000x000000XY010x0000XY00100x00XY00XY110xXYXYXYXY这个复制能力是 A32 完全没有的。想想0xXYXYXYXY这种模式在 A32 里除非 XY 是 0x00 或 0xFF否则想都别想一条指令搞定而在 Thumb-2 里一条就够。模式二当最高两位不全为 0 时取0b1拼上imm12[6:0]组成 8 位种子旋转量取imm12[11:7]这 5 位取值范围 0 到 31不限于偶数。这一点比 A32 强意味着那些起点在奇数位的 8 位窗口现在也能表示了比如 0x102 这种在 A32 里绝对不合法的值Thumb-2 可以一条指令加载。5.3 三种编码方式的横向对比把 A32、16 位 Thumb、Thumb-2 三者的能力摊开对比差异一目了然编码方式指令位宽立即数字段可表示的典型值A32 数据处理328 位种子 4 位偶数旋转0xFF000000、0x104、0x8100Thumb 16 位168 位无旋转0 到 255Thumb-2 数据处理3212 位i:imm3:imm8上述全部外加 0xXYXYXYXY 和奇数起点窗口实际工程里的经验是开了 Thumb-2 之后因为立即数不合法而产生的额外指令会显著减少但又没有完全消失。像 0x12345678 这种真正的随机数任何模式都装不下还是得靠MOVW/MOVT或者文字池。跨架构移植的时候同一个汇编片段在 ARM 状态能过、切到 Thumb 状态就报错绝大多数情况就是撞在这个位宽差异上。6. AArch64 的重新设计位模式立即数与 12 位算术立即数6.1 ADD/SUB 的 12 位加左移 12到了 64 位时代做架构的人干脆把问题拆成两类分别用不同的编码方式解决。第一类是算术立即数用在ADD、SUB、CMP、CMN上编码是 12 位 imm12 加一个 1 位的sh标志。sh 0时直接取值 0 到 4095sh 1时表示 imm12 左移 12 位得到 4096 到 16777215 之间步长为 4096 的值。这套规则简单到不需要任何种子 旋转的心智负担。你只要记住两个区间小整数直接写大整数按 4KB 页对齐。内存访问指令的偏移量也是同样的编码这也是为什么 AArch64 的加载偏移上限是 4095 字节或者按 8 字节缩放的 32KB 左右和这个设计一脉相承。add x0, x1, #100 // 0 到 4095 区间 add x0, x1, #0x1000, lsl #12 // 等价于加 0x10000006.2 逻辑立即数的 bitmask 编码怎么判第二类是逻辑立即数用在AND、ORR、EOR、ANDS以及 64 位版本的MOV别名MOVZ之外的那个上。这部分用的是 13 位的N:immr:imms编码表达能力比 A32 强得多但判定逻辑也复杂得多。不用管具体的解码公式实用的判定方法是三条找到这个值在 64 位环上的最小重复单元单元长度必须是 1、2、4、8、16、32、64 这些 2 的幂这个单元内必须是循环连续的 1也就是从某一位开始的一串 1允许跨越单元边界环绕整个 64 位值必须是这个单元的不间断重复。举几个例子就清楚了。0xFF00FF00FF00FF00的最小重复单元是 0xFF长度 8 位单元内是 8 个连续 1整个值就是 0xFF 重复 8 次合法。0x5555555555555555的单元是 2 位单元内是01从 bit0 看只有一个 1循环看是连续的合法。0x00000000000001FF的单元长度必须是 64 位因为低 9 位是 1、高位全 0任何更小的单元重复都会产生非零高位64 位环上从 bit0 到 bit8 是连续 9 个 1也算循环连续合法——这个值在 A32 里是绝对不行的正好体现了两代架构的差异。反面例子是0x12345678最小重复单元只能是 32 位0x12345678 本身单元内 1 的分布散乱不构成循环连续段非法。再比如0x0000000081000000两个 1 分别位于 bit24 和 bit31中间隔了 6 位 064 位环上从 bit31 绕到 bit24 又是 7 位 0两头都不连续非法。如果你要写工具做判定思路和前面的 Python 代码类似只不过循环单元长度和循环连续的判断要复杂一些def check_a64_logic_imm(v): v 0xFFFFFFFFFFFFFFFF for esize in (2, 4, 8, 16, 32, 64): mask (1 esize) - 1 unit v mask # 检查整个值是否是 unit 的重复 if v ! unit * (0xFFFFFFFFFFFFFFFF // mask): continue # 检查 unit 内部是否为循环连续的一段 1 s bin(unit)[2:].zfill(esize) doubled s s ones unit.bit_count() if ones 0: return True if s in (0 * (esize - ones) 1 * ones, 1 * ones 0 * (esize - ones)): return True # 更通用的写法检查 doubled 中是否出现连续 ones 个 1 if 1 * ones in doubled: return True return False
