操作系统任务切换时，如何确定需保存的寄存器？

一、硬件架构的硬约束是基础 #

任何CPU架构都会定义一套调用约定——简单来说就是规定函数调用时哪些寄存器由调用者负责保存，哪些由被调用者负责保存。任务切换本质上是打断当前任务执行、跳去执行内核调度逻辑的过程，必须保证恢复任务时，它的执行状态和被打断时完全一致。

按照这个逻辑，必须保存的寄存器分两类：

• 被调用者保存寄存器：架构规定这类寄存器的值在函数调用后必须保持不变，所以切换时必须保存——毕竟调度过程相当于一次“隐式的函数调用”，内核调度函数不能破坏这些寄存器的值。
• 核心控制寄存器：比如程序计数器（PC/R15）、栈指针（SP/R13）、链接寄存器（LR/R14），这些是任务执行的核心上下文，不保存的话根本无法恢复任务。

你之前在ARM上全存R1-R15确实冗余，比如R0-R3属于调用者保存寄存器，如果当前任务已经把这些寄存器的值存到自己的栈上了，切换时其实没必要额外保存。只是入门实现为了简化逻辑，才会选择全存，用性能换代码复杂度。

二、操作系统实现决定优化空间 #

硬件只给出了最低要求，剩下的优化完全由操作系统设计决定：

• 按需保存“脏寄存器”：如果内核能跟踪哪些寄存器被当前任务修改过且未写入内存，就只保存这些“脏”寄存器。但这种跟踪需要额外开销，一般只有追求极致性能的生产级内核会做。
• 抛弃笨重的硬件任务切换：比如x86的TSS段，硬件自动保存大量寄存器但性能拉胯——这是早期为简单多任务设计的，现代操作系统基本都放弃了这种方式，改用软件实现上下文切换，只保存必要寄存器，减少不必要的内存读写。
• 任务状态结构的定制：如果操作系统的任务状态只包含最核心的执行上下文（PC、SP、被调用者保存寄存器），保存的内容自然更少。比如用户态轻量级线程，甚至只保存PC和SP，其他寄存器靠调用约定让用户自行管理。

三、实际开发的最佳实践 #

1. 严格遵循架构的调用约定：这是避免上下文不一致bug的最稳妥方式，比如ARM的AAPCS、x86的System V AMD64 ABI都有明确规定，照着做不会出错。
2. 入门实现全存，高性能实现按需优化：新手写内核时，全存寄存器能快速跑通任务切换，先保证功能再谈性能；但生产级内核必须做优化，比如只保存被调用者保存寄存器+核心控制寄存器，调用者保存寄存器让任务自己在栈上处理。
3. 不依赖硬件任务切换：硬件自带的任务切换通用性强但效率低，软件实现更灵活，能根据调度策略定制保存内容，性能提升明显。

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