为何上下文切换中未对FPU寄存器执行保存与恢复操作？

这个问题问到点子上了！这里核心是性能优化和硬件-操作系统协同设计的权衡，咱们掰开了说：

• FPU的使用频率远低于通用寄存器
  大部分进程（比如很多后台服务、简单的命令行工具）根本不会涉及浮点运算。如果每次上下文切换都强制保存/恢复FPU的一堆寄存器，会平白消耗大量CPU周期，拖慢整个系统的响应速度。操作系统采用了「延迟懒加载」的策略——只在进程真正需要使用FPU的时候，才触发保存/恢复操作。

• 硬件提供了精准的状态追踪支持
  以x86架构为例，CPU里有个CR0.TS（Task Switched）状态位：当进程切换后，这个位会被置1。如果当前进程第一次尝试执行浮点指令，CPU会立刻触发设备不可用异常（#NM）。操作系统的异常处理程序会接手：

  1. 先把上一个使用过FPU的进程的寄存器状态保存到它的进程控制块（PCB）里；
  2. 如果当前进程之前用过FPU，就从它的PCB里恢复FPU寄存器；如果没使用过，就初始化FPU状态；
  3. 最后清掉CR0.TS位，让浮点指令继续执行。
     这套机制完全由硬件+操作系统配合完成，精准且没有额外的性能浪费。

• 关于「调度时机不当导致内容丢失」的担忧
  其实完全不用担心！因为只有当进程主动使用FPU时，才会触发上下文的保存/恢复。一旦某个进程使用过FPU，它的FPU状态就会被存在PCB里，下次切换时，要么是在新进程触发FPU异常时被保存，要么是操作系统在必要时（比如进程被挂起前）主动保存——硬件的状态位会准确追踪FPU的占用者，不会出现状态丢失的情况。

简单总结：这种设计是在「性能开销」和「功能正确性」之间找到的最优解——避免了无意义的操作，同时通过硬件辅助确保了FPU状态的安全。

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