题目

执行系统调用的过程涉及下列操作，其中由操作系统完成的是（ ）。

Ⅰ. 保存断点和程序状态字 Ⅱ. 保存通用寄存器的内容 Ⅲ. 执行系统调用服务程序 Ⅳ. 将 CPU 模式改为内核态

错因

A

把 Ⅰ（保存断点和 PSW）误归到了 OS。但 PC 和 PSW 的压栈是 CPU 在响应陷入指令的那一瞬间自动完成的——OS 还没开始跑，怎么可能动手？Ⅱ（保存通用寄存器）才是 OS 进了内核后用 push 一个个保存的。两者发生在不同时刻。

C

把 Ⅳ（切换到内核态）误归到了 OS，又漏了 Ⅲ。CPU 模式位是 PSW 里的一个 bit，用户态根本没权限去改它——若 OS 能"自己切换"，那等于说切换前它就已经在内核态了，逻辑成环。模式切换必须由硬件在执行 trap 指令时自动完成。

D

跟 C 同样把 Ⅳ 算到 OS 头上。如果用户态能改 PSW 的模式位，"用户程序想升内核就升内核"，OS 的安全隔离立刻瓦解——所以模式切换硬件必管，OS 不能、也不需要自己来。

总解析

系统调用从用户态发起到返回的整段流程，硬件和 OS 各管一段，分界点是"用户态指令流被打断的瞬间"——前者是硬件做的"最低限度准备"，后者是 OS 进入内核后的全套处理。

按时间顺序拆开：

步骤	谁做	备注
执行 trap / syscall 指令	用户进程	把系统调用号放进约定寄存器
保存断点 PC 和 PSW	硬件	CPU 自动压栈（对应 Ⅰ）
切换 CPU 模式 → 内核态	硬件	trap 指令触发时由硬件直接改 PSW.mode（对应 Ⅳ）
跳转到陷阱入口	硬件	查中断向量表
保存通用寄存器	OS	入口代码 push 各寄存器（对应 Ⅱ）
解析系统调用号、分发	OS	查系统调用表
执行系统调用服务程序	OS	真正的 read / write / ... 函数（对应 Ⅲ）
恢复通用寄存器	OS	pop
恢复 PC、PSW，返回用户态	硬件	iret / sysret

逐项归属：

操作	谁做
Ⅰ 保存断点和 PSW	硬件
Ⅱ 保存通用寄存器	OS ✓
Ⅲ 执行系统调用服务程序	OS ✓
Ⅳ 改 CPU 模式为内核态	硬件

OS 做的是 Ⅱ、Ⅲ。

记忆要点：只要涉及"PC / PSW 这两个特殊寄存器"或"模式位"的改动，都是硬件做的——因为这些操作都得在用户态权限不够的情况下完成，必须靠硬件自动机制。剩下那些"用普通指令就能做的事"（保存通用寄存器、查表、调函数）才轮到 OS。

最终答案是 B。