做嵌入式开发这些年,我经常看到不少工程师在一个平台上已经把某个概念吃透了,换到另一个架构上却开始犯迷糊。就拿处理器运行模式和寄存器组来说,Cortex-M和Cortex-A的基本概念看起来都是“寄存器”、“模式”、“特权”,但如果你把M核那套思维直接套到A核上,轻则汇编代码写得别扭,重则在移植RTOS或写底层启动代码时直接踩坑。这篇文章我就用实际开发者的视角,把两类内核的运行模式和寄存器组摆在一起,逐项对比,把背后的设计意图也讲清楚。
这套知识适合谁?系统学习嵌入式底层、准备做内核移植、或者平时写驱动但对架构细节一知半解的朋友。对比的目的不是判断谁优谁劣,而是搞清楚两个分支的差异到底从哪里来、各自为了解决什么问题。讲清楚这些,你对两个平台的理解都会比单纯看手册更透彻。
1. 两个架构的设计源头:为什么差这么远
1.1 从目标场景倒推设计思路
理解Cortex-M和Cortex-A的差异,得先看它们各自的出生背景。Cortex-M是设计给MCU市场的,目标是替代传统8位/16位单片机,同时把实时性做得更好。所以它天生就非常在意中断响应速度、低功耗、代码密度,以及让裸机开发尽量简单。
Cortex-A是设计给应用处理器市场的,对应的是跑Linux、Android这类复杂操作系统的场景。这类场景需要的是内存管理单元MMU、高速缓存、深层流水线、多核扩展,甚至虚拟化支持。为了支撑复杂操作系统,ARM在Cortex-A上保留了“经典ARM处理器”那一套复杂的模式和寄存器分组设计。
一个直接结果是:Cortex-M的中断控制器NVIC直接集成在处理器内部,中断到来时硬件自动帮你做了大量状态保存工作。Cortex-A则依赖外部的中断控制器,通常叫GIC(Generic Interrupt Controller),中断进来后CPU本身要做更多软件处理,模式切换的复杂度明显更高。
1.2 指令集与异常模型的分叉点
Cortex-M只支持ARM Thumb/Thumb-2指令集,不存在ARM状态。Cortex-A完整支持ARM状态与Thumb状态,甚至可以动态切换。这听起来只是指令集宽度的问题,实际上连带影响了异常处理、寄存器使用方式和状态保存策略。
异常模型上,两者的差距更加本质。Cortex-M用一套统一的“堆栈保存”机制:任何异常发生时,硬件自动把xPSR、PC、LR、R12、R3、R2、R1、R0这八个体压栈,具体压到哪个堆栈取决于当前的堆栈指针是MSP还是PSP。Cortex-A则是“模式切换+寄存器分组”机制:异常发生后CPU自动切换到一个特权模式,并切换到该模式专属的堆栈指针,同时把返回地址和状态保存到专用寄存器中,通用寄存器的保存要靠软件完成。这种差异直接决定了两者在RTOS中的上下文切换写法完全不同。
所以,你要记住一个核心结论:Cortex-M的设计哲学是“硬件帮软件做掉大部分现场保护”,Cortex-A则仍然保留“软件管理上下文”的传统思路。理解了这一点,后面所有模式和寄存器的细节都顺理成章。
2. 运行模式对比:两套截然不同的模式体系
2.1 Cortex-M的运行模式:少即是多
Cortex-M内核只有两种运行模式,外加两种特权等级。
- 线程模式(Thread Mode):芯片复位后默认处于该模式,日常主程序、裸机循环、RTOS任务大部分都运行在这里。线程模式既可以处于特权级,也可以处于非特权级,具体由CONTROL寄存器的nPRIV位决定。
- 处理模式(Handler Mode):所有异常和中断都在这个模式下处理,而且永远是特权级。你可以把它理解为CPU“进入内核态”的专用状态。
这个设计的最大好处是足够简单。中断来临时CPU自动切换到处理模式,处理完异常返回时再自动切回线程模式,你不用在软件里手动维护模式状态。Cortex-A里那种“我当前到底在哪个模式”的焦虑,在M核上几乎不存在。
很多人会被另外一个问题绕住:线程模式和非特权级是不是绑定关系?不是。线程模式可以跑在特权级,比如你刚复位后、还没有配置CONTROL寄存器的时候。RTOS里,如果跑的是特权级任务,任务上下文就在线程模式+特权级下执行;如果任务跑在非特权级,内核的SVC异常在特权级处理,任务则在线程模式+非特权级执行。理解这个矩阵(两种模式×两种特权级)对后面分析堆栈切换很关键。
2.2 Cortex-A的运行模式:八种模式的传统架构
Cortex-A运行模式源自经典ARM架构,一共八种:
- USR(用户模式):非特权模式,应用程序运行的地方。这也是八个模式里唯一非特权的模式。
- FIQ(快速中断模式):专门给快速中断用的特权模式,拥有独立的一组寄存器。
- IRQ(普通中断模式):普通中断处理时进入的特权模式。
- SVC(管理模式):复位后CPU进入的模式,操作系统内核通常运行在此。Linux内核的大部分执行上下文就在SVC模式。执行SVC指令主动发起系统调用,也会陷入该模式。
- ABT(中止模式):访问内存异常时进入,常用于处理数据中止或预取中止。
- UND(未定义模式):遇到未定义指令时进入。
- MON(监视器模式):用于TrustZone安全扩展的安全监控调用。
- HYP(虚拟化模式):支持虚拟化扩展时,Hypervisor运行的模式。
可以这样理解:Cortex-M用“少数模式+硬件自动分工”来表达需求,Cortex-A用“多个特权模式+每个模式独立分工”来表达需求。
2.3 模式与特权等级的关系对照表
下面这个表格是我自己整理的,方便快速对照两种架构的模式、对应特权等级、进入方式和用途。
| 处理器 | 运行模式 | 特权等级 | 进入方式 | 典型用途 |
|---|---|---|---|---|
| Cortex-M | 线程模式 | 特权或非特权 | 复位后默认;通过CONTROL控制 | 主程序、RTOS任务 |
| Cortex-M | 处理模式 | 特权 | 中断/异常触发 | 全部异常与中断处理 |
| Cortex-A | USR | 非特权 | 软件切换到其他模式后回用户态 | 应用程序 |
| Cortex-A | FIQ | 特权 | FIQ中断触发 | 高速中断处理 |
| Cortex-A | IRQ | 特权 | IRQ中断触发 | 普通中断处理 |
| Cortex-A | SVC | 特权 | SVC指令/复位 | 操作系统内核、系统调用 |
| Cortex-A | ABT | 特权 | 数据/指令中止 | 内存访问异常处理 |
| Cortex-A | UND | 特权 | 未定义指令 | 非法指令异常处理 |
| Cortex-A | MON | 特权 | 安全监控调用 | TrustZone安全世界切换 |
| Cortex-A | HYP | 特权 | 虚拟化扩展相关 | Hypervisor虚拟化管理 |
拍脑袋记一下:除了USR外,几乎每个异常源都对应一个独立的特权模式。为什么这样设计?因为操作系统需要一个机制来区分“我是谁”:当前代码运行在用户态、内核态、还是中断上下文,直接影响访问权限和堆栈选择。Cortex-A直接通过“模式”来编码这个状态,这是和Cortex-M最大的思路差异。
2.4 深入理解:Cortex-A为什么保留这么多模式
有读者会问:M核已经把模式简化到两个了,为什么A核不也这样子做?
关键在于使用场景。应用处理器上跑的是复杂的操作系统,操作系统需要严格的权限隔离:应用程序不能直接操作硬件,内核可以;普通中断上下文与内核上下文最好分开,避免中断处理破坏内核状态;虚拟化场景下还要有Hypervisor隔在操作系统和硬件之间。没有多模式支持,这些隔离和权限控制很难高效率实现。
你可以把Cortex-A的每个模式理解为一套独立的“运行环境”,切换模式不只是改变权限,还顺带切换了一套寄存器备份。这种硬件层面的备份让模式切换非常快。相比之下,如果让Cortex-M强行依靠软件保存寄存器来实现多级隔离,频繁切换的开销会大得多。这就是A核保留传统多模式结构的根本原因:性能与复杂度的权衡。
要把A核的模式管理好,最佳实践是:在启动早期,先用软件把CPU放到SVC模式并设置好独立的SVC堆栈;把中断的栈单独分配;用户态则通过修改CPSR切到USR并配置用户态堆栈。每个模式都有独立SP,这是Cortex-A底层代码设计和M核一个很大的不同。
3. 寄存器组对比:分组方式和可用寄存器差异
3.1 Cortex-M的寄存器组:统一且扁平
Cortex-M的寄存器组相对清爽:
- R0-R12:通用目的寄存器,其中R0-R7是低寄存器,可以被更多16位指令访问,Thumb-1时代这八个寄存器是主力;R8-R12是高寄存器,部分16位指令不能直接访问。
- R13:堆栈指针,在Cortex-M中可以映射到MSP或PSP。
- R14:链接寄存器(LR),保存函数返回地址或异常返回特殊值。
- R15:程序计数器(PC)。
- xPSR:程序状态寄存器,由应用程序PSR、中断编号PSR和执行状态PSR组成。
- PRIMASK、FAULTMASK、BASEPRI:中断屏蔽专用寄存器。
- CONTROL:控制寄存器,用于选择堆栈指针、控制特权等级,以及是否使用浮点单元。
这里有几个Cortex-M特有细节值得强调。一是LR不只是存储调用返回地址,在异常处理时,它会被硬件填入一个特殊值(EXC_RETURN),这个值的含义包括“异常返回后进入线程模式还是处理模式”“使用MSP还是PSP”“返回后是否还保持特权”。二是NVIC自动压栈只会保存部分寄存器,如果中断里用到了R4-R11或被中断的代码本身有额外的寄存器需求,仍然需要在软件里处理。三是BASEPRI这个寄存器很实用,它可以屏蔽低于某优先级的中断,而允许高优先级中断继续进来。
3.2 Cortex-A寄存器组:分组建制是核心
Cortex-A的寄存器组明显更复杂,核心概念是“分组寄存器”:
- R0-R15:通用寄存器。R0-R12无分组,R13(SP)、R14(LR)和R15(PC)是特殊共享的。
- CPSR:当前程序状态寄存器,保存条件标志、中断屏蔽位、模式编号等。
- SPSR:保存的程序状态寄存器,每个异常模式都有独立的SPSR,用来保存被中断前CPSR的值。
真正体现“分组”特色的,是下面这组映射关系:
| 模式 | 拥有独立备份的寄存器 |
|---|---|
| USR | R13_USR、R14_USR(与SVC等模式共享寄存器文件,但SP/LR各不相同) |
| FIQ | R8_FIQ-R12_FIQ、R13_FIQ、R14_FIQ、SPSR_fiq |
| IRQ | R13_IRQ、R14_IRQ、SPSR_irq |
| SVC | R13_SVC、R14_SVC、SPSR_svc |
| ABT | R13_ABT、R14_ABT、SPSR_abt |
| UND | R13_UND、R14_UND、SPSR_und |
| MON | R13_MON、R14_MON、SPSR_mon |
| HYP | R13_HYP、R14_HYP、SPSR_hyp |
FIQ模式独占R8-R12这一组,这是它被称为“快速中断”的根本原因:一进入FIQ模式,就有五个额外的通用寄存器可以随便用,几乎不需要压栈,上下文切换开销极小。为了追求极致速度,牺牲了一部分通用寄存器的数量。实际开发中,如果某个中断要求极低延迟且处理逻辑不太复杂,可以考虑这个方向,这种设计至今仍有参考价值。
3.3 两个架构寄存器使用的实际影响
寄存器数量上的差异,对编译器生成的代码质量影响很大。Cortex-A因为有16个通用寄存器,加上ARM模式下的丰富寻址方式,可以运行比较复杂的代码而不频繁访问栈。Cortex-M大部分代码在R0-R7之间打转,高寄存器虽然也能用,但指令密度和灵活度受限,这也是Cortex-M的代码相对“秀气”的原因——不过它走的是低功耗高密度路线,平衡下来依然很高效。
让我用一个具体例子说明这个差异带来的编码手感。在Cortex-M上,你写一个函数,参数通常通过R0传递,返回结果也是R0,局部变量优先用R4-R11,因为这些寄存器在异常压栈时不会自动保存,但C语言编译器会遵循AAPCS规则将它们视为需保存寄存器。在Cortex-A上,编译器可以更随意地使用R0-R12传递参数和表达式临时值,只有R4-R11需要保存。表面看起来只是寄存器多了一点,但真实的代码密度和执行性能差距非常大。
3.4 状态寄存器:CPSR与xPSR的差别
Cortex-M的xPSR包含三类子状态:应用PSR(APSR)、中断编号PSR(IPSR)、执行状态PSR(EPSR)。APSR里主要是条件标志N、Z、C、V以及饱和标志Q;IPSR保存当前中断编号;EPSR保存Thumb位和可中断-可继续指令相关的状态。访问它们可以通过MRS/MSR指令,XPSR整体可读写。
Cortex-A的CPSR则承担所有职责:条件标志位、中断屏蔽位I和F、Thumb状态位T、模式位M[4:0],以及后来的异步中止标志、虚拟化标志等。它既是状态寄存器,也是控制寄存器,通过修改CPSR的M位来切换模式、通过修改I/F位来开关中断。
特别提醒:在Cortex-A中修改CPSR切换模式时,一定要小心。因为CPSR的修改会立即生效,如果你当前在USR模式想切到SVC,直接改M位会触发非法模式切换,必须通过异常机制(SVC指令)或先进入特权模式再改。此外,同时修改多个位域时,建议用“读-改-写”而不是直接写入整值,以免误改别的标志位。
4. 异常处理与堆栈机制:两种完全不同风格
4.1 异常向量表与入口差异
Cortex-M的向量表是一组地址表,每个异常对应表中的一项,项内放的是处理函数的入口地址。系统复位后从向量表偏移0处读出初始SP,从偏移4处读出复位向量。向量表在FLASH或RAM中都可以,通过VTOR寄存器配置基地址。
Cortex-A的向量表则是一段指令跳转表,每一项放的是跳转指令或加载PC的指令。经典的异常入口通常写在启动汇编里,通过“ldr pc, label”方式跳转到对应的C函数。AArch64(64位模式)下的异常向量表更复杂,分为不同异常等级和异常类型的组合项。也就是说,M核的向量表是“数据表”,A核的向量表是“指令表”,这个区别在写链接脚本和启动代码时非常重要。
4.2 Cortex-M的硬件压栈与堆栈指针选择
Cortex-M异常进入时,硬件自动将xPSR、PC、LR、R12、R3-R0这8个寄存器压栈。具体压到哪个栈,由当前使用的SP决定:如果当前使用MSP,压到MSP;如果当前使用PSP,压到PSP。可能压到进程栈,也可能压到主栈,这完全取决于被中断的代码上下文。
这带来了一个常见面试题场景:中断服务程序里,当前SP可能还是PSP,也可能已经切到MSP。硬件压栈后,自动切到MSP;退出时根据EXC_RETURN恢复对应的SP。在RTOS里,每个任务都有自己的独立栈(PSP),中断使用系统主栈(MSP)。这就是为什么上下文切换时要把PSP恢复给任务:所有任务的现场都在各自的栈里保存着。
需要注意一个细节:如果启用浮点单元,并且在任务或中断处理中使用了FPU寄存器,异常进入时会自动多压一组S0-S15和FPSCR,总共多占约72字节。这时候除了八寄存器压栈,还有一个额外的“FPU寄存器压栈”步骤。用FPU中断时务必保证栈空间足够,否则容易出现莫名其妙的栈溢出。
4.3 Cortex-A的软件保存策略
Cortex-A异常进入时,硬件只做三件事:保存CPSR到SPSR,保存返回地址到LR,切换到异常模式并开始执行异常向量。它不像M核那样自动压栈通用寄存器。所以Cortex-A的中断处理汇编代码开头,几乎永远是“先压一堆寄存器”或者“先切换到自己的栈,再压寄存器”。
这个特点让Cortex-A的上下文切换比M核更“自由”,但也更容易出错。比如在IRQ模式中,如果你需要在IRQ模式下调用一个C函数,必须保证该模式下SP是有效且独立的,否则会破坏系统栈。而且在Cortex-A中,由于不同模式有不同SP,很多启动代码都要做“每个模式设置独立栈”这步操作。操作系统中的进程切换、内核线程切换,通常都需要先切换到SVC模式,再保存当前任务上下文,然后加载新任务上下文,最后通过修改SPSR等操作完成“异常返回到用户态”。整个流程比M核复杂,但可定制性更高。
4.4 中断嵌套能力对比
Cortex-M通过NVIC天然支持中断嵌套:高优先级中断可以抢占低优先级中断,硬件自动完成压栈/出栈,每个中断入口都共享同一个异常向量处理流程。而且由于压栈入栈操作是硬件自动的,切换到高优先级中断时,低优先级中断的现场已经在栈中,不会被破坏。
Cortex-A本身没有内置中断嵌套逻辑。IRQ模式的进入意味着CPU已经关闭了IRQ中断(I位自动置1)。如果你希望在中断处理过程中允许高优先级中断抢占,必须在软件里手动重新开IRQ,并注意保存好LR和SPSR。换句话说,A核的中断嵌套不是一个“默认功能”,而是由软件(通常是操作系统或中断控制器驱动的软件架构)来构建的。这也是很多从M核转到A核的开发者最初极不适应的点。
4.5 异常返回机制:EXC_RETURN vs CPSR恢复
M核的异常返回靠LR里的EXC_RETURN特殊值:该值被加载到PC后,硬件解析它来决定从哪个栈恢复现场、恢复哪些寄存器、回到哪个模式。由于这个机制非常清晰,裸机中断处理只需写出“BX LR”这类指令,就能自动完成返回过程。A核则是通过“从SPSR恢复CPSR”的方式:在异常返回时,执行“movs pc, lr”或“subs pc, lr, #4”等指令,将PC设为LR,同时将SPSR复制到CPSR,从而同时完成PC跳转和状态恢复。
这里有个经典细节:A核中,IRQ返回时,由于LR保存的是被中断指令地址+4,需要先偏移修正;FIQ类似,也是+4;而SVC和预取中止要使用不同的偏移值。不同模式返回时的偏移量不同,新手非常容易写错。建议写底层代码前,先在ARM手册上把每种异常对应的LR偏移表抄下来贴在调试台上。
5. 操作系统与RTOS适配:模式与寄存器的实战影响
5.1 M核上的RTOS上下文切换思路
在Cortex-M上实现RTOS,通常的做法是:
- 主栈MSP给内核和中端使用;
- 每个任务拥有独立的PSP栈;
- 任务切换发生在PendSV异常里,在PendSV中先把当前任务的R4-R11、SP等压入该任务栈,然后更新TCB中的SP值;
- 切换新任务时,从新任务TCB中恢复SP,弹出R4-R11,再从异常返回机制返回到新任务的现场。
由于M核硬件已经自动保存了R0-R3、R12、LR、PC、xPSR,任务切换时软件只需要额外保存R4-R11。很多RTOS的上下文切换代码因此很短。在M核上,你不必关心“当前是否在特权模式”,只要保证任务栈足够大、PendSV优先级设置合理即可。
5.2 A核上的操作系统上下文切换思路
在Cortex-A上跑Linux或大型RTOS,上下文切换通常发生在SVC模式或IRQ模式里。以嵌入式Linux为例,用户进程运行在USR模式,内核运行在SVC模式。系统调用通过SVC指令进入内核,内核保存用户态寄存器到进程的内核栈,执行内核代码,返回时恢复用户态寄存器,并切回USR模式。整个过程涉及CPSR模式的反复切换。
中断处理则通常在IRQ模式发生。如果中断发生在用户态,CPU自动切换到IRQ模式,同时把被打断的用户态CPSR保存到SPSR_irq,把返回地址保存到LR_irq。内核中断处理代码负责将用户态的现场进一步保存到内核栈中,然后切换到SVC模式继续处理或调度。最终通过异常返回到用户态。整个过程的手工痕迹非常重,也因此A核底层代码对寄存器保存顺序有严格约定,哪怕漏存一个寄存器,也会导致不可预知的状态损坏。
5.3 移植代码时容易踩的寄存器坑
- 把M核的“异常进入时硬件保存了PC”的假定带到A核。A核异常进入时只保存返回地址到LR,你若没有维护好LR,就可能丢失返回地址。
- 在A核中直接用M核风格的“PendSV”概念。A核没有PendSV,一般是用IRQ或软中断实现调度。
- 在M核中错误地假设多个模式有独立SPSR。M核只有一个xPSR,不像A核每个模式有SPSR,没有“不同模式各自保存状态”这种硬件机制。
- 忘记M核是统一编址、通常无MMU;A核需要配合MMU建立页表。寄存器操作之外,内存管理差异远大于模式差异。
6. 实际开发中的经验与建议
6.1 选择方案时的思路建议
如果你做一个工业控制、传感器采集、电机驱动这类强实时应用,Cortex-M更顺手:中断延迟低、上下文切换简单、外设集成度高、低功耗好做。如果你的产品需要跑复杂的用户界面、网络协议栈、或者要兼容第三方生态软件,Cortex-A加操作系统几乎是必然选择,哪怕它有更复杂的模式管理,收益也远大于代价。
我自己接触过的某个跨平台系统项目中,团队一开始用M核实现了全部业务逻辑,产品中期要加一个比较复杂的网络管理界面,才发现M核资源紧张,不得不切换到A核方案。迁移过程中,底层异常处理部分被反复重写,花费的时间比预期多很多。这提醒我们:选择架构时不能只看“当前需求”,要评估三年内产品演进的路径。
6.2 从M核转向A核的学习路径建议
如果你现在M核玩得很熟,想在A核上快速上手,建议这样走:
- 第一步,把CPSR和每模式SP/LR/SPSR这个分组关系刻进脑子。
- 第二步,动手写一个最精简的启动汇编:复位后设置各模式SP,切换到SVC模式,开IRQ,进入C主函数。
- 第三步,写一个手动触发的中断处理,比如定时器中断,完整走一遍“进IRQ-压栈-处理-出栈-返回”的流程。
- 第四步,再试着在A核上写一个最简单的“任务切换”,用两个模式模拟两个任务上下文,手动切换。
只要这四个步骤走完,你对A核的把握就已经超过很多只写过应用代码的开发者。反过来,如果从A核转向M核,重点理解“硬件压栈帮你做了什么”即可。很多A核工程师第一次看到M核的PendSV切换代码会惊讶于它如此简短,原因正是硬件把大事都做了。
6.3 调试工具和技巧分享
调试寄存器问题时,我通常会用调试器直接查看当前CPSR和SPSR。在M核上,直接查看xPSR、CONTROL和当前SP即可。有一个很实用的踩坑经验:用调试器看M核当前栈指针变化时,要分清当前是MSP还是PSP,别被“SP变了”误导。很多新手在调试RTOS时,明明任务栈已经溢出,却盯着MSP看,半天查不出问题。
在A核上,建议打开调试器的寄存器窗口,同时观察CPSR的M位、I/F位以及当前SP。如果异常一进来SP是乱七八糟的值,大概率是异常模式的SP没有初始化。先检查启动代码里各模式SP是否都正确设置,再去排查逻辑问题。这一步能省掉大量定位时间。
7. 常见问题与排查技巧实录
7.1 为什么M核的中断里改动LR要格外小心?
因为M核异常返回靠LR特殊值。在中断服务程序里,如果你调用了一个函数,LR会被函数调用覆盖,必须先把LR保存到栈中或者用其他寄存器保存。如果中断程序里直接使用LR做数据搬运,没有意识到它此时的特殊身份,返回时就会跳到错误地址。我见过不少因为这个“LR被覆盖”导致的HardFault,几乎都是初学者会踩的经典坑。
7.2 A核的IRQ模式里SP没有初始化会出现什么情况?
如果IRQ模式的SP是零或无效地址,中断一旦触发,压栈操作就会导致数据写到一个不可访问的内存,进而触发数据中止异常,甚至陷入死循环。启动代码里必须为每个用到的异常模式单独设置SP。有些人偷懒只设置了SVC模式的SP,结果中断一进来就“翻车”。这套义务在Cortex-M上不存在,因为M核的所有异常都使用MSP,除非你特意选择了PSP。
7.3 如何在M核上读取当前是MSP还是PSP?
使用MRS指令读取CONTROL寄存器的SPS位。如果SPS为0表示使用MSP,为1表示使用PSP。注意,以线程模式运行且SPS为1时,当前SP是PSP;以处理模式运行且SPS为1时,仍然可能使用PSP,但异常入口会自动压栈到PSP,然后切换为MSP。别把“模式”与“SP选择”混成一谈。
7.4 在A核上如何进入用户态并保留操作系统的访问权?
典型的做法是:在SVC模式中设置好用户态栈指针和返回地址,然后修改SPSR_svc的M位为USR模式,并设置I/F位等状态,最后执行“movs pc, lr”之类的指令,既跳转到用户代码,同时SPSR拷贝到CPSR,完成从特权级到用户态的切换。这个过程中,由于之前是在特权级修改SPSR,所以可以完成任意模式设置;一旦回到USR后,就不能再直接修改CPSR的模式位,只能通过异常系统调用返回内核。
7.5 两个架构里,printf这类“重操作”放在中断里有什么不同后果?
M核和A核都建议不要在中断里做重活,但约束角度略有不同:M核由于自动压栈和NVIC优先级设计,长时间占据中断会导致其他低优先级中断延迟;A核则因为中断处理使用IRQ模式且默认关IRQ,如果不及时重开IRQ,比M核更容易出现中断丢失或延迟。实际上,两个平台的主流做法都是把中断里的工作做到最小,把耗时操作放到线程/内核上下文里执行。
8. 一些实际体会与扩展方向
对比完Cortex-M和Cortex-A的模式与寄存器组,我最深刻的体会有两点。第一,这两套设计不是“进步”与“落后”的关系,而是对“简单实时控制”和“复杂系统生态”两种需求作出的不同取舍。第二,真正能让你水平提升的不是背下每个寄存器的名字,而是理解硬件设计者当时在权衡什么:为什么FIQ要额外给五个寄存器?为什么M核要引入PSP?为什么A核把异常模式细分?这些问题想通了,你以后看任何芯片手册都会更快。
如果后续想深入,可以做几个扩展方向:一是把AArch64状态下的异常等级(EL0-EL3)与本文提到的八模式对应起来,你会发现传统模式概念在64位时代被重新抽象了。二是自己动手在Cortex-M上写一个极简RTOS的上下文切换,对比在Cortex-A上写一个极简调度器,这两种练习会帮你把今天讲的所有知识点串联成肌肉记忆。
对我个人而言,这种“M与A对比”的价值恰恰在于,它逼迫你跳出某一个平台的舒适区,去读手册之外的设计意图。下次你要是也遇到平台迁移或者从零选型,希望这篇文章能帮你少走点弯路。
