为何ARM架构中程序状态寄存器（CPSR）不会被压入栈中？

• 效率与语义的权衡：Thumb指令集的核心是紧凑高效，普通子程序调用（比如BL）大多不会修改CPSR的关键状态（如标志位、处理器模式）。如果默认每次调用都保存恢复CPSR，需要额外执行MRS读、压栈、出栈、MSR写这些指令，会无谓增加代码体积和执行开销，不符合Thumb的设计初衷。

• CPSR的特殊访问限制：CPSR不能像R0-R12这类通用寄存器一样直接用PUSH/POP操作，必须通过MRS（读CPSR到通用寄存器）和MSR（写通用寄存器到CPSR）指令间接访问。这种特殊性让它无法被纳入通用寄存器的默认压栈流程，只能在有明确需求时手动处理。

• 调用约定的职责划分：按照ARM的调用约定（如AAPCS），CPSR属于调用者自行负责保存的状态。如果调用者的后续逻辑依赖当前CPSR的状态（比如标志位），它需要在调用子程序前手动执行MRS Rn, CPSR+PUSH {Rn}来保存，子程序本身无需默认承担这个工作。这种设计让调用者根据实际需求灵活处理，避免了一刀切的冗余操作。

• 与异常场景的本质区别：只有在异常（中断、软中断等）发生时，硬件才会自动把CPSR保存到对应模式的SPSR中——因为异常会强制切换处理器模式、修改CPSR状态，必须保存才能恢复到异常前的执行环境。但普通子程序调用不属于异常范畴，没有硬件自动保存的机制，软件层面也没将其纳入默认保存列表。

内容的提问来源于stack exchange，提问作者Bas