2、硬件架构对上下文切换的影响：CPU内核架构（ARM Cortex-M vs RISC-V）、寄存器组大小、浮点单元（FPU）的影响
聊上下文切换，很多人第一反应是「软件算法够不够快」。但说实话，真正决定切换开销上限的，是硬件本身。你想想看，CPU 内核架构不同，寄存器数量不同，有没有 FPU，这些硬性条件直接决定了你要保存和恢复多少东西。
我这些年调过不少 RTOS 内核，从 ARM Cortex-M 到 RISC-V 都折腾过。每次换平台，上下文切换的代码都得重写一遍。为什么？因为硬件不一样，套路就不一样。今天我就把这块掰开揉碎了讲讲。
2.1 ARM Cortex-M 的硬件特性
ARM Cortex-M 系列在嵌入式领域太常见了。它的上下文切换有个天然优势——硬件自动压栈。
当异常或中断发生时，Cortex-M 的硬件会自动把 R0-R3、R12、LR、PC、xPSR 这 8 个寄存器压到当前栈上。这意味着什么？意味着你写 PendSV 切换代码时，这部分工作已经帮你干完了。
我个人习惯把这种设计叫做「半自动切换」。你只需要手动保存 R4-R11 这 8 个寄存器，加上 PSP 指针，总共也就 9 个寄存器。代码量很小，执行时间也很稳定。
关键点：Cortex-M 的 PendSV 异常优先级最低，专门用来做上下文切换。硬件自动压栈 + 软件手动压栈，组合起来效率很高。
我在项目中遇到过一个问题：某次调试时发现切换时间忽长忽短。查了半天，原来是中断嵌套导致的。Cortex-M 在中断嵌套时，硬件压栈次数会变多，栈空间占用也翻倍。嗯，这里要注意，如果你的系统中断嵌套很深，栈空间得留够。
2.2 RISC-V 的硬件特性
RISC-V 这边情况就不同了。它没有硬件自动压栈机制。所有寄存器，包括通用寄存器、PC、状态寄存器，都得靠软件手动保存和恢复。
RISC-V 的寄存器组比 Cortex-M 大不少。标准 RV32I 架构有 32 个通用寄存器，其中 x1 是返回地址寄存器，x2 是栈指针。切换时，除了 x0（恒为 0）不用管，其他 31 个寄存器都得处理。
你想想看，31 个寄存器 vs Cortex-M 的 9 个，光数量就差了三倍多。每次切换多保存 22 个寄存器，这开销可不是闹着玩的。
我的建议：在 RISC-V 上做 RTOS，可以考虑只保存被调用者保存寄存器（callee-saved registers）。这样能减少一半左右的保存量。但前提是你的任务切换逻辑得设计好，别漏了关键寄存器。
我曾经在一个 RISC-V 项目上踩过坑。当时为了追求极致性能，我自作聪明地只保存了部分寄存器。结果某个任务跑着跑着就崩了，查了两天才发现是某个临时寄存器没保存，被另一个任务覆盖了。从那以后，我老老实实按规范来，该保存的一个不少。
2.3 寄存器组大小的影响
寄存器组大小直接影响上下文切换的存储开销。咱们来算笔账：
| 架构 | 需保存的寄存器数量 | 每次切换存储量（32位） | 典型切换时间（CPU周期） |
|---|---|---|---|
| ARM Cortex-M3/M4 | 9（R4-R11 + PSP） | 36 字节 | 约 40-60 周期 |
| RISC-V RV32I | 31（x1-x31） | 124 字节 | 约 120-180 周期 |
| RISC-V RV32E | 15（x1-x15） | 60 字节 | 约 60-90 周期 |
看到没？RISC-V 的 RV32I 比 Cortex-M 多了将近 90 字节的存储量。如果你的系统任务切换很频繁，这差距会直接体现在 CPU 占用率上。
不过 RISC-V 也有个变种叫 RV32E，只有 16 个寄存器。这个设计就是专门为低成本、低功耗场景准备的。如果你选这个架构，切换开销会小很多。
2.4 浮点单元（FPU）的影响
FPU 这东西，用好了是神器，用不好就是性能杀手。为什么？因为 FPU 寄存器组太大了。
ARM Cortex-M4 和 M7 都带了 FPU。FPU 有 32 个单精度寄存器（S0-S31），每个 32 位。如果任务用了浮点运算，切换时这些寄存器都得保存和恢复。32 个寄存器就是 128 字节，加上之前的 36 字节，总共 164 字节。
我记得有个项目是做音频处理的，大量使用浮点运算。一开始没做优化，每次上下文切换要保存 164 字节。后来我加了个懒加载机制——只在任务确实用了 FPU 时才保存 FPU 寄存器。切换时间直接降了一半。
避坑指南：我曾经在一个 Cortex-M4 项目上，所有任务都开启了 FPU 寄存器保存。结果切换时间从 50 周期飙升到 200 周期。后来发现大部分任务根本没用浮点运算。白白浪费了性能。
RISC-V 这边也有 FPU，标准叫法叫 F 扩展（单精度）和 D 扩展（双精度）。F 扩展有 32 个浮点寄存器（f0-f31），每个 32 位。D 扩展同样 32 个寄存器，但每个 64 位。切换开销比 ARM 只大不小。
我的经验是：能用定点就别用浮点。实在要用，就做懒加载。或者把浮点运算集中到少数几个任务里，其他任务不碰 FPU。这样大部分切换都能跳过 FPU 寄存器的保存。
2.5 架构选择建议
说了这么多，到底选哪个架构？我个人的看法是：
- 追求低延迟、高确定性：ARM Cortex-M 是首选。硬件自动压栈让切换时间非常稳定，适合实时性要求高的场景。
- 追求灵活性、开源生态：RISC-V 更有优势。你可以定制寄存器数量，甚至去掉 FPU 来降低切换开销。
- 浮点运算密集：两个架构都得小心。做好懒加载，或者考虑用硬件加速器替代 FPU。
最后说一句：上下文切换的性能调优，不是光看架构就行的。你得结合自己的应用场景，实测、分析、再优化。纸上谈兵没用，跑起来才知道问题在哪。