为什么寄存器压栈这个动作会“慢”到需要专门设计一套复杂的“懒压栈”机制？
其实并不是FPU本身运行慢，而是“内存访问”相对于“处理器处理速度”太慢了。我们可以从以下三个维度来拆解这个原因：
1、数据的“量”级差异：从8个到25个在没有FPU的情况下，Cortex-M进入中断时硬件会自动压栈8个通用寄存器（RO-R3,R12,LR,PC,xFSR)。一旦开启FPU 且任务使用了浮点运算,硬件需要额外压栈17个寄存器（S0-S15和FPSCR）。
普通中断：8个寄存器 x 4字节 = 32字节
FPU中断：（8+17）个寄存器 × 4字节 = 100字节
要把这100字节数据从CPU寄存器写入RAM，需要消耗大量的总线周期。对于追求“确定性”和“低延迟”的实时系统（RTOS）来说，这种翻倍的压栈时间是不可接受的。
2. 关键瓶颈：总线与内存
虽然CPU核心频率很高（比如200MHz），但内存（SRAM）和总线接口往往跟不上这个速度。
指令执行：CPU内部处理加减法可能只需要1个周期。
内存写入：连续写入25个字（Word）可能需要几十个甚至上百个时钟周期（取决于等待周期、总线竞争等）。
中断延迟：ARM Cortex-M的卖点之一就是极快的中断响应（通常12个周期左右)。如果每次进中断都要老老实实把FPU寄存器存完，这个响应时间可能直接变成40-50个周期。
3. “无用功”的浪费
在嵌入式开发中，绝大多数的中断服务函数（ISR）其实根本不涉及浮点运算。
如果没有Lazy Stacking：即使你的ISR只是为了清理一个定时器标志位，CPU也会强行把那17个浮点寄存器存入堆栈，然后出中断再取回来。这纯粹是浪费电力和执行时间。
有了Lazy Stacking：只有当你真的在ISR里写了类似 float = b * 1.5f 的代码时，CPU才会“极不情愿”地停下来去完成压栈。
后记：寄存器，名称，作用（通俗解释）
R0-R3:通用寄存器，搬砖工。函数调用时的前4个参数通常放在这里，也是计算时最常用的临时存数位。
R12:内部调用暂时寄存器(IP),临时工。通常用于在函数调用间隙暂时存放数据。
LR(R14):链接奇存器(Link Register),回冢的路。保存函数返回后的地址,或者中断返回时的特殊编码(EXC_RETURN)。
PC(R15):程序计数器(Program Counter),指挥棒。指向CPU当前正在执行(或即将执行)的那行代码的地址。
xPSR:组合程序状态寄存器,仪表盘。记录当前运算是否溢出、是否有进位,以及当前处在哪个中断编号里。