3、ARMv7-A与ARMv8-A架构对比：32位与64位的那些事儿
好，咱们今天聊点硬核的。ARMv7-A和ARMv8-A，这两个架构的对比，说白了就是32位时代和64位时代的分水岭。很多刚入行的朋友会觉得，不就是从32位升到64位嘛，寄存器宽了点，寻址空间大了点。嗯，这么说也没错，但实际远不止这么简单。
我个人习惯把ARMv8-A看作是一次「推倒重来」的设计。它保留了AArch32来兼容老代码，但核心的AArch64完全是另一套玩法。你想想看，一个架构里塞了两套指令集、两套寄存器模型、两套异常模型，这在处理器设计里其实挺「奢侈」的。但ARM为什么要这么做？说白了，就是为了既照顾老客户，又能在服务器、高性能计算这些新战场上跟x86掰手腕。
3.1 指令集差异：AArch32 vs AArch64
先看指令集。AArch32就是咱们熟悉的ARMv7-A那套，支持ARM和Thumb-2两套指令集。AArch64呢？它只保留了一套固定32位长度的指令，不再有Thumb模式了。
核心变化：
- AArch32：支持ARM（32位）和Thumb-2（16/32位混合）
- AArch64：仅支持A64（固定32位指令）
- AArch64取消了条件执行（大部分指令），改用条件选择指令
- AArch64新增了大量SIMD（NEON）和加密扩展指令
我记得第一次在AArch64上写汇编时，习惯性地给一条ADD指令加了条件后缀，结果编译器直接报错。当时愣了一下，才反应过来——AArch64里大部分指令都不支持条件执行了。那怎么实现条件分支？用CSEL（条件选择）指令。比如：
// AArch32 写法（ARM模式）
CMP R0, #0
ADDNE R1, R2, R3 // 如果R0!=0，则R1=R2+R3
// AArch64 写法
CMP W0, #0
CSEL X1, X2, X3, NE // 如果条件NE成立，X1=X2，否则X1=X3
这个变化其实挺大的。条件执行在ARMv7时代是个大杀器，能减少分支预测失败的开销。但到了64位时代，ARM觉得为了性能，还是把条件执行砍掉大部分，改用更简单的流水线设计。嗯，这里要注意，不是完全取消，像B.cond这类分支指令还是带条件的。
避坑指南：我曾经在移植一个ARMv7的加密库到AArch64时，发现大量使用了条件执行的指令。手动改成CSEL和CSINC花了不少功夫。如果你也在做类似移植，建议先看看有没有现成的AArch64版本，别自己硬改。
3.2 寄存器模型：从31个到31个，但完全不一样
这个标题有点绕是吧？ARMv7-A有16个通用寄存器（R0-R15），其中R15是PC。ARMv8-A的AArch64也有31个通用寄存器（X0-X30），但用法完全不同。
| 特性 | ARMv7-A (AArch32) | ARMv8-A (AArch64) |
|---|---|---|
| 通用寄存器数量 | 16个（R0-R15） | 31个（X0-X30） |
| PC寄存器 | R15（通用寄存器之一） | PC（独立寄存器，不可直接访问） |
| SP寄存器 | R13（与通用寄存器共享） | SP（独立寄存器，有EL专属版本） |
| LR寄存器 | R14（与通用寄存器共享） | X30（专用链接寄存器） |
| 零寄存器 | 无 | XZR/WZR（读取为0，写入忽略） |
| 寄存器宽度 | 32位 | 64位（也可用Wn访问低32位） |
这里有个细节我特别想强调：AArch64的PC不再是一个通用寄存器了。你不能像在ARMv7里那样直接读PC来计算地址。为什么？因为ARM想简化指令集的设计，让流水线更干净。你想想看，如果PC是个通用寄存器，那很多指令的副作用就变得复杂了。
另外，AArch64引入了「零寄存器」XZR。这个设计很巧妙。当你需要给某个寄存器赋0时，直接写MOV X0, XZR就行，不需要像ARMv7那样先加载一个0到内存再读进来。我在做性能优化时经常用这个技巧，能省一条指令。
注意：AArch64里X30是专用的链接寄存器（LR），不像ARMv7里R14可以被当作普通寄存器用。如果你在AArch64里不小心把X30当临时变量用了，返回时就会跳到一个莫名其妙的地方。我曾经见过一个同事因为这个bug调了三天，最后发现是LR被覆盖了。
3.3 异常模型：从7种模式到4个异常等级
这个变化可能是最颠覆的。ARMv7-A有7种处理器模式（User、FIQ、IRQ、Supervisor、Abort、Undefined、System），每种模式有自己的寄存器组。ARMv8-A完全抛弃了这套，改用4个异常等级（Exception Level，EL0-EL3）。
为什么会这样？我个人理解，ARMv7的模式设计虽然灵活，但太复杂了。尤其是虚拟化场景下，Hypervisor和Guest OS之间的切换非常麻烦。ARMv8的EL模型把这个问题彻底解决了：
- EL0：用户态（非特权）
- EL1：操作系统内核
- EL2：Hypervisor（虚拟化）
- EL3：Secure Monitor（安全世界）
每个EL都有自己的SP、SPSR（保存的程序状态寄存器）和异常向量表。异常发生时，处理器会根据当前EL和目标EL自动切换栈指针和状态保存。这比ARMv7手动切换模式要安全得多。
我记得在做一个安全启动方案时，需要在EL3和EL1之间来回切换。ARMv7时代，你得小心翼翼地保存和恢复各种模式下的寄存器。到了AArch64，直接用SMC指令就能从EL1陷入EL3，系统自动帮你处理好上下文。嗯，省心不少。
异常向量表的变化：
- ARMv7：每个模式有自己的向量表基址（可配置）
- AArch64：每个EL有独立的向量表，通过VBAR_ELx寄存器设置
- AArch64的向量表有4个入口（同步、IRQ、FIQ、SError），每个入口又分4种情况（SP_EL0、SP_ELx、AArch64、AArch32）
- 总共16个向量，每个向量可以放16条指令（不再是一条跳转指令）
这个16条指令的设计很有意思。ARMv7的异常向量表每个入口只有一条指令的空间，通常放一条跳转指令。AArch64给了你16条指令的空间，很多简单的异常处理可以直接在向量表里完成，不需要跳转。这对中断延迟的优化很有帮助。
3.4 实战中的选择建议
说了这么多，到底该用AArch32还是AArch64？我个人的经验是这样的：
- 如果是在做裸机或RTOS项目，且内存小于4GB，AArch32完全够用。它的工具链更成熟，调试起来也更顺手。
- 如果跑Linux，建议直接上AArch64。现在主流发行版对64位ARM的支持已经很完善了，而且64位的内核能更好地利用大内存和硬件虚拟化。
- 如果要做安全相关开发，AArch64的EL模型比ARMv7的模式切换要清晰得多。TrustZone在AArch64下实现得更优雅。
一个小技巧：很多Cortex-A系列处理器（比如Cortex-A53、A72）都支持AArch32和AArch64两种状态。你可以在启动时通过SCR_EL3的RW位选择进入哪种状态。我习惯在Bootloader阶段先用AArch32初始化一些外设，然后切换到AArch64启动内核。这样既能利用32位下成熟的驱动代码，又能享受64位的高性能。
好了，关于ARMv7-A和ARMv8-A的对比，咱们就聊到这儿。下一节我会深入讲讲AArch64的异常处理流程，包括同步异常、IRQ、FIQ和SError的具体处理方式。到时候咱们再细聊。