写了好几年高级语言，我第一次正经坐下来读ARM汇编时，最别扭的不是MOV、也不是LDR，而是分支结构——明明是一个if-else的事情，汇编里却拆成了“比较”和“跳转”两件事，还动不动冒出一堆BGT、BEQ、BNE。后来把CMP指令、CPSR状态标志和条件后缀三者的关系理顺之后，再看分支代码就顺多了。这篇文章就是把我这段理解过程写下来：先拆ARM分支的底层机制，再拿几个完整例子逐行走读，顺便把多路开关、Thumb模式差异和调试时常踩的坑一起讲透。适合那些刚接触ARM汇编、或者C语言写得还行但一读反汇编就头大的开发者。
1. 分支结构在ARM底层到底拆成了什么
1.1 高级语言一行分支，在ARM里面是什么样
高级语言里写if (x > 0)就是一行，但在ARM汇编里，这句话几乎不可能用一条指令完成。ARM把“判断”拆成了两步：先用比较指令算出两个数的相对关系，把结果记录到状态寄存器里；再用跳转指令去读这个状态，决定要不要改变程序的执行顺序。也就是说，你看到的不是“如果大于0就跳过去”，而是“先比较”“再根据比较结果跳转”两个动作。
这个设计初看很绕，实际是故意的。比较结果是一次性的、可以被多个跳转复用。比如你写一个多条件的else-if链，CMP R0, #0执行一次，后面可以连续接好几个条件跳转指令来分别测试大于、小于、等于、大于等于等等，而不需要每次都重新做减法。这比每个判断都重新算一遍要高效得多。
理解这一层之后，ARM汇编里的分支结构就有了固定的阅读套路：先找CMP或类似改标志位的指令，再看跟在后面的条件跳转指令的后缀，最后把两者拼起来还原出高级语言的逻辑。
1.2 ARM分支与x86的典型差异
如果你学过x86汇编，再看ARM会发现一个很有意思的差别：x86也有CMP和JE、JNE这类指令，但x86几乎没有“大多数指令都可以带条件执行”的概念。ARM则不同，在A32（ARM状态）下，绝大多数指令都能挂上一个条件后缀，比如ADDNE、MOVEQ、LDRLT，意思是“满足这个条件才执行，不满足就当作什么都没发生”。
这意味着ARM上的分支有两种实现路径：一种是传统意义上的跳转，另一种是用条件执行直接跳过不需要的指令，完全不出现在PC跳跃。举个最小例子，实现“x>0则返回1，否则返回0”：
CMP R0, #0 MOVGT R0, #1 MOVLE R0, #0 BX LR这段代码里根本没有B开头的跳转指令。MOVGT只在x大于0时把R0改成1，MOVLE只在x小于等于0时把R0改成0，两条里恰好只有一条会真正执行。这就是ARM条件执行的威力。x86里想省掉跳转基本做不到，但ARM从指令集层面就给了你另一条路。
这个差异决定了读ARM分支代码时的思考方式：看到一个if逻辑，不一定非要去寻找跳转标签，也可能只是一串带条件后缀的指令在互斥执行。
1.3 建立正确的指令心智模型
我建议初学者在心里给ARM指令做一个简单分类：一类负责“算数并送结果到寄存器”，另一类负责“算数并送结果到状态标志位”。分支关注的是后者。CMP就是典型的“只改标志位、不写通用寄存器”的指令，它背后做的是减法，但减出来的结果扔掉了，只把这次减法对N、Z、C、V这四位标志的影响记录下来。
整个执行流程可以想象成：取指→译码→执行→检查条件→决定PC的走向。条件跳转指令本身不改变标志位，它只是“读”标志位。这个读写分离的模型贯穿ARM分支结构的全部设计。后面所有章节都是在这个模型上展开的。
2. CMP和CPSR状态标志：分支判断的真正引擎
2.1 CMP：只改签，不打分
CMP指令的完整语义可以理解为SUBS Rd, Rn, Operand2之后丢弃掉Rd的结果，只保留标志位变更。它没有目标寄存器，所以写起来是CMP R0, #5或者CMP R0, R1这种形式。指令执行后，R0和R1的值都不变，变的只有CPSR寄存器里的条件标志。
把“比较”做成不写回结果的减法，有个直接好处：你不用担心比较动作会污染原有数据。比如CMP R0, #5执行完，R0仍然是原来那个数，后面还能继续用它做别的运算。这在高级语言里很正常，但底层CPU设计时，是需要刻意避免“比较指令顺手改掉寄存器”这种反直觉行为的。
除了CMP，还有几个同样只更新标志位的表兄弟：CMN（与相反数相加）、TST（按位与测试）、TEQ（按位异或测试）。其中TEQ只影响Z标志，专门用来判断“是否完全相等”，在实现精确比对时很干净。但日常分支代码里，CMP出现频率最高，优先级也最高。
2.2 NZCV四颗标志位管什么
CPSR的低四位标志位是分支判断的核心依据，分别是N、Z、C、V，看名字容易懵，把它们对应到“一次减法运算的结果”上就清楚了。
N（Negative）是结果最高位，也就是有符号数视角下的正负号。结果为负时N=1，结果为正或零时N=0。注意它只看bit31，不管数值大小。
Z（Zero）最简单，结果为零就置1。判断两个数相等，本质就是看相减后Z是否为1。
C（Carry）在算术逻辑单元里承担两种角色：做加法时它表示进位，做减法时它表示“没有借位”。减法中C=1意味着被减数不小于减数，无符号比较就靠它。
V（Overflow）记录有符号溢出。两个同号数相减或异号数相加时，结果超出了有符号可表示范围，V就会置1。它的存在让“结果虽然算出来了，但已经不可信”这种情况可以被程序感知到。
这四个标志合在一起，就是CPU对一次比较给出的“批注”。批注本身没有业务含义，是程序用不同的条件后缀去解释它们。
2.3 条件后缀完整对照表
ARM给指令设计了十几种条件后缀，每个后缀对应一组标志位条件。这张表建议收藏：
| 后缀 | 含义 | 标志位条件 |
|---|---|---|
| EQ | 相等 | Z=1 |
| NE | 不相等 | Z=0 |
| CS / HS | 无符号大于等于 | C=1 |
| CC / LO | 无符号小于 | C=0 |
| MI | 负数 | N=1 |
| PL | 正数或零 | N=0 |
| VS | 有符号溢出 | V=1 |
| VC | 无符号溢出未发生 | V=0 |
| HI | 无符号大于 | C=1 且 Z=0 |
| LS | 无符号小于等于 | C=0 或 Z=1 |
| GE | 有符号大于等于 | N=V |
| LT | 有符号小于 | N≠V |
| GT | 有符号大于 | Z=0 且 N=V |
| LE | 有符号小于等于 | Z=1 或 N≠V |
| AL | 无条件执行 | 始终成立 |
这些后缀既能用于B跳转指令（如BEQ、BGT），也能用于其他指令的条件执行（如MOVNE、ADDLE），语义完全一致。换句话说，你会读BGT，就会读MOVGT。
2.4 有符号比较和无符号比较千万别混
同一个CMP结果，既可以按无符号解释，也可以按有符号解释，但选错后缀就会得出完全相反的逻辑。来看一个例子：CMP R0, R1，其中R0=0xFFFFFFFF，R1=0。硬件做减法得到的标志是：C=1、Z=0，因为0xFFFFFFFF-0没有借位也不是零。如果按无符号解释，0xFFFFFFFF是4294967295，确实大于0，所以BHI成立，正确；但如果按有符号解释，0xFFFFFFFF是-1，小于0，BHI同样成立，显然就是错的。正确的有符号判断应该用BLT或BGT系列。
所以写分支前，第一个要确定的问题就是：参与比较的双方是有符号类型还是无符号类型。这个类型不是写在指令里的，而是写在你选用的条件后缀里的。你用什么后缀，就相当于告诉CPU“请按哪种世界观解释这套标志位”。
3. 基础if-else场景下的完整汇编走读
3.1 一个三次判断的sign函数
为了把常见的比较分支都串起来，我们用经典的三态符号函数做例子，C语言逻辑如下：
int sign(int x) { if (x > 0) return 1; if (x == 0) return 0; return -1; }对应的A32汇编可以写成这样，参数x已经在R0里，返回值也放R0：
sign: CMP R0, #0 BGT .L_pos BEQ .L_zero MOV R0, #-1 BX LR .L_pos: MOV R0, #1 BX LR .L_zero: MOV R0, #0 BX LR这段代码很短，但几乎覆盖了分支结构的所有基础要素：一个CMP喂出标志位，两条条件跳转各取所需，一个隐含的“否则”分支在两条跳转都不发生时继续往下走。
3.2 逐行走读：每条指令到底在干什么
第一条CMP R0, #0执行减法R0-0，结果本身丢弃，但N、Z、C、V四个标志被更新。接下来BGT .L_pos检查的是：Z=0且N=V。假如x是正数，比如x=5，那么结果是正数，N=0、V=0、Z=0，条件满足，跳转到.L_pos，R0被赋值为1后返回。
假如x=0，CMP执行后Z=1。BGT一看Z不是0，条件失败，不跳。紧接着的BEQ .L_zero只要Z=1就跳，于是跳去给R0赋0并返回。
假如x是负数，比如x=-3，那么BGT失败、BEQ也失败，程序自然落到MOV R0, #-1这条指令上，完成了“否则”分支。整个过程里没有一条B无条件跳转指令去跳过别的分支，靠的是条件跳转失败时PC自动顺序走向下一条指令。这个“顺序落下”的行为，就是else分支最底层的实现方式。
这里还有一个值得注意的细节：BGT和BEQ用的都是同一个CMP留下的标志位，因为条件跳转指令本身不改变标志位，所以可以连续判断多个条件。如果你在BGT和BEQ中间插了一条会改标志位的指令，后面的判断就会失效，这一点后面调试章节还会重点讲。
3.3 编译器会把分支重排成什么样子
手写汇编时为了可读性，常把正数、零、负数三个处理块顺序排开。但编译器在优化时往往会根据概率调整布局，把大概率路径保持在顺序流上，尽量减少跳转次数。比如假设“x大于0”最常见，编译器可能生成类似这样的结构：
CMP R0, #0 BLE .L_not_pos MOV R0, #1 BX LR .L_not_pos: BEQ .L_zero MOV R0, #-1 BX LR .L_zero: MOV R0, #0 BX LR同样是sign函数，但正数分支不再单独放在远处，而是紧跟CMP之后。如果x确实大于0，只需要执行一个BLE然后直接返回，少了一次额外的跳转。虽然现代处理器有分支预测，跳转不一定贵，但在循环热点或分支密集的代码里，这种布局差异是实打实的性能变量。
看懂编译器怎么重排，对调试也很有用。你反汇编时看到的标签位置往往和源码里的if顺序不完全一致，这不一定是你写错了，更可能是编译器做了路径布局优化。
4. 复杂多路分支：从比较链到跳转表
4.1 比较链：逻辑最直白的写法
当分支不止两条时，最直观的做法就是一条接一条地比较。比如switch有case 1、2、3、5四路，用比较链写出来大概是这样：
CMP R0, #1 BEQ .L_case1 CMP R0, #2 BEQ .L_case2 CMP R0, #3 BEQ .L_case3 CMP R0, #5 BEQ .L_case5 B .L_default每个case代价是两条指令：一次CMP加一次条件跳转。最坏情况下要比较完所有case才落到default。它的优点是逻辑和源码一一对应，内存占用为零，值域稀疏时特别合适。缺点是case一多，最坏路径会很长。假设有20个case，最坏要走40条指令才能命中，指令缓存压力也上来了。
所以比较链适合case数量少、或者case值分布非常散乱的场景。比如case值分别是1、100、1000、10000，无论做跳转表还是哈希表都要额外处理空洞，比较链反而是最省心的。
4.2 跳转表：用连续内存换时间
如果case值是一个比较密集的整数区间，跳转表是更经典的做法。思路是把每个case分支的目标地址按顺序存在一张表里，用“输入值减去区间起点”算出索引，然后一次性跳到对应地址。核心指令就一句：
CMP R0, #1 BLT .L_default CMP R0, #5 BGT .L_default SUB R1, R0, #1 ADR R2, .L_jt LDR PC, [R2, R1, LSL #2] .L_jt: .word .L_case1 .word .L_case2 .word .L_case3 .word .L_default .word .L_case5边界检查保证R0落在1到5之间后，SUB R1, R0, #1把输入转换成0到4的索引，LDR PC, [R2, R1, LSL #2]从表基址加上索引乘以4的位置取出一个32位地址，直接把它写入PC，实现跳转。表里第4项故意填default地址，于是case 4虽然没有对应处理，也会安全落在default分支上。
这段代码无论命中哪个case，固定执行量都差不多：两次边界检查、一次减法、一次基址加载、一次PC加载。case再多，也只是表变大，指令数量不变。这正是跳转表的核心优势：用数据换时间。
4.3 两种方案怎么选
比较链和跳转表不是非此即彼，编译器在真实工程里会综合判断。给你一个可以抄的判断标准：
| 判断维度 | 比较链 | 跳转表 |
|---|---|---|
| case数量少（3个以内） | 推荐 | 不划算 |
| 值域密集连续 | 一般 | 推荐 |
| 值域稀疏 | 推荐 | 表太大会浪费 |
| 内存极其紧张 | 推荐 | 需要额外存表 |
| 最坏路径耗时 | 随case数增长 | 基本固定 |
手工写汇编时，我会在case数超过4个且值域跨度不太大时首选跳转表。这里有个常见误解：跳转表不是“case多就一定快”，如果值域从1到1000但只有5个case，做一张1000项的表纯属浪费，这时候比较链或者两级查表更合理。
4.4 跳转表实现时最容易翻车的点
跳转表实现起来要小心几个坑。第一，表项必须是字对齐的32位地址。.word伪操作在ARM里通常会自动对齐到4字节，但如果你手动拼接数据，就要确保每项确实占4字节。第二，表的地址要么和代码紧挨着，要么明确链接到固定地址。上面示例用ADR取表基址，隐含条件是表和这条ADR指令距离不能太远；如果工程里把表放在另一个段，最好改用LDR R2, =label这种能从字面量池加载绝对地址的方式。第三，跳转表里填的是目标地址的绝对地址，如果整个固件还要支持位置无关重定位，就要额外处理重定位项，否则跳到错地址是分分钟的事。
我第一次手写跳转表时就在对齐上吃过亏，表里漏了一个.align，导致索引算出来总差几个字节，PC加载出来的地址错位，程序直接飞到非法地址。从那以后我养成了习惯，写完表数据立刻检查每个地址是不是4字节对齐。
5. Thumb模式下分支结构的差异与If-Then块
5.1 Thumb模式让条件执行变稀缺
前面讲的条件后缀主要是A32（ARM状态）的特性。嵌入式里大量使用的Cortex-M系列处理器运行在Thumb模式，准确的说是Thumb-2指令集。Thumb-1的设计目标是压缩代码密度，很多指令没有条件执行能力，分支主要靠传统的比较加跳转。到了Thumb-2，ARM又用If-Then块把条件执行拉了回来，但形式上比A32要啰嗦一些。
如果你只在Cortex-M上写汇编，第一次看到IT开头的指令不必慌，它就是Thumb-2里承担“条件执行”职责的语法结构。
5.2 IT块的语法和读法
IT指令全称是If-Then，后面可以跟最多3个T或E字符，控制接下来最多4条指令是否条件执行。举一个最典型的if-else例子：
CMP R0, #0 ITE EQ MOVEQ R1, #1 MOVNE R1, #2ITE里的T表示随后第一条指令在条件为真时执行，E表示随后第二条指令在条件为假时执行。所以这段代码读作：如果R0等于0，R1赋1，否则R1赋2。后续指令的条件后缀必须和IT块的T/E定义一致，否则就是非法编码。
再看一个两条then加一条else的写法：
CMP R0, #0 ITTE EQ MOVEQ R1, #1 MOVEQ R2, #2 MOVNE R2, #3这里ITTE里两个T一个E，于是前两条指令在R0等于0时执行，第三条指令在R0不等于0时执行。
阅读IT块的技巧很简单：数一数IT后面有几个字符，就知道后面有几条受控指令；按照T和E的位置，把条件后缀分成“真执行组”和“假执行组”，逻辑就还原出来了。
5.3 手写IT块的常见错误
我见过最多的问题是把IT块的T/E顺序和指令后缀搞反。比如有人想把“相等时R1=1，否则R1=2”写成：
ITE EQ MOVNE R1, #1 MOVEQ R1, #2这个写法是错的。ITE已经规定了第一条是EQ、第二条是NE，但代码第一条写的是NE。大多数汇编器会直接报“condition conflict”，有些旧工具链甚至不报错，生成出来的行为完全不可控。所以显式写IT块时，我的习惯是先写IT行，再按顺序写指令，每写一条都回头核对一次条件。
还有一点提示：现在很多统一汇编器足够智能，你直接写MOVEQ、MOVNE这种带条件的指令，它会在编译时自动推断并插入正确的IT块。但在启动代码、异常处理这种对指令编码特别敏感的地方，我还是建议显式写IT，可读性和可控性都好很多。
6. 调试分支代码时容易踩的坑与实测经验
6.1 调试前，先把CPSR窗口打开
调分支代码和调普通运算代码最大的不同是，你需要时刻盯着一组“看不见的中间量”——标志位。我调试时做的第一件事就是在调试器里打开CPSR寄存器的视图，把N、Z、C、V四个位单独列出来，然后单步执行CMP，观察标志位变化是否和预期一致。
有个很实用的自查习惯：在CMP指令前先口头说出“接下来标志会变成什么样”，再步过CMP去对照。比如R0=0x80000000时执行CMP R0, #0，按有符号理解这是个负数，所以N=1、Z=0、V=0。接下来如果要判断负数，应该走BLT，因为LT要求N≠V，这里明显满足；如果走BGT，GT要求N=V且Z=0，这里N=1、V=0，不满足。这个事前推导能帮你快速发现自己是不是选错了条件后缀。
6.2 四个高频翻车场景
第一个坑是标志位被中途覆盖。CMP之后不是所有指令都安全，普通MOV、LDR、STR确实不改标志位，但带S后缀的数据处理指令ADDS、SUBS、MOVS、ANDS以及CMP、TST、CMN、TEQ都会重新写标志位。如果在CMP R0, R1后面插了一条MOVS R2, #0，再想用BEQ判断R0和R1是否相等，结果一定不是你想要的。
第二个坑是有符号无符号条件码混用。前面说过，判断“大于等于”时，无符号用BHS，有符号用BGE，两者看着相似但依据不同。尤其注意BGE和BHS的边界值差异：有符号比较中，0xFFFFFFFF代表-1，它小于0；无符号比较中它是4294967295，大于0。同一个数，用错一组后缀，逻辑直接反转。
第三个坑是跳转表跳飞。常见原因是表项未对齐、表基址地址不对或表里填入了错误地址。处理这种问题我一般先在LDR PC那条指令上打断点，检查R2和R1的值，手动心算目标地址，再查看目标内存里是不是合法的分支指令开头。
第四个坑是ARM立即数编码限制。很多人写CMP R0, #0x12345678时汇编器报错，还以为是语法问题。ARM的立即数不是任意32位数，它由8位基值配合循环移位编码而成，很多常量没法直接表示。解决办法是先用LDR R1, =0x12345678这条伪指令把常量加载到寄存器，再CMP R0, R1。不是所有“看着能写”的常数都能直接塞进指令编码里。
6.3 让编译器当你的分支结构老师
如果身边没有精通汇编的老手，最好的老师其实是编译器。写一个简单的C文件，用交叉编译工具链编译后反汇编，能看到编译器在相同逻辑下生成的完整分支结构。比如写一个if-else判断，加-O2优化后，编译器有时会用条件执行替代跳转，有时会把冷分支挪到函数末尾，有时会为switch生成跳转表。这些生成代码就是活教材。
我会拿编译器生成的分支代码和自己手写的对照，重点看三件事：CMP放在什么位置、条件后缀选了哪一组、分支块里的指令顺序为什么这样排。看得多了，再回手写汇编，选指令和排布局都会自然很多。
最后再分享一个小技巧：我读任何一段分支汇编之前，都会先在纸上写出CMP双方的“预期类型”——有符号还是无符号、期望的命中条件是什么，然后再去反推应该用的条件后缀。这个习惯帮我在日常调试里省下了大量反复单步的时间。分支结构在ARM里看着指令多，但本质就是“比较+标志位+条件后缀”这三件事的排列组合，把这三件事想清楚，剩下的都只是套模板。
