4. RISC-V特权模式与异常处理：机器模式、监管模式、用户模式的异常处理差异
各位同学，咱们今天聊一个硬核话题——RISC-V的三种特权模式在异常处理上的区别。说实话，我刚接触RISC-V那会儿，也被这些模式绕得有点晕。但后来在FPGA上实际跑过几个项目后，发现这东西其实没那么玄乎。
简单来说，RISC-V定义了三种特权级别：机器模式（M-mode）、监管模式（S-mode）和用户模式（U-mode）。它们就像公司里的三个层级——老板、经理和普通员工。异常来了，谁有权处理、怎么处理，完全取决于你当前在哪个层级。
核心观点：异常处理的核心差异在于——谁捕获异常、谁处理异常、以及异常返回后谁继续执行。这三个问题，不同模式给出的答案完全不同。
4.1 机器模式（M-mode）—— 最高权限，兜底处理
M-mode是RISC-V的“根”模式。说白了，它就是那个永远有最终决定权的角色。我在项目中习惯把M-mode当作“硬核管家”——所有异常它都能处理，而且它不依赖任何其他模式。
M-mode的异常处理有几个关键点：
- 异常入口固定：M-mode的异常向量基地址由
mtvec寄存器控制。你可以把它指向一个直接处理函数，也可以指向一个向量表。 - 异常原因明确：
mcause寄存器告诉你发生了什么异常。是非法指令？还是访问违例？一目了然。 - 异常值辅助：
mtval寄存器会存放异常相关的附加信息，比如出错的地址或指令编码。 - 返回机制：用
mret指令返回。它会从mepc中取出返回地址，同时恢复mstatus中的MPP字段，告诉你之前是在哪个模式下运行的。
嗯，这里要注意：M-mode的异常处理是同步的。也就是说，异常发生时，处理器会立即跳转到异常处理程序，不会像中断那样可以被屏蔽（除非你主动关掉全局中断使能位）。
个人经验：我在一个RISC-V核的FPGA实现中，曾经把M-mode的异常处理写得过于复杂——在异常处理里又调用了可能触发异常的函数。结果呢？死循环了。后来我学乖了：M-mode的异常处理一定要保持简洁，最好只用汇编写一个轻量级的handler。
4.2 监管模式（S-mode）—— 操作系统的主场
S-mode是给操作系统用的。Linux、FreeRTOS这些系统，跑的就是S-mode。为什么？因为S-mode提供了虚拟内存管理（通过satp寄存器）和独立的异常处理机制。
S-mode的异常处理流程和M-mode类似，但有几个关键差异：
- 异常向量：由
stvec寄存器控制。你可以选择直接模式（所有异常跳转到同一个地址）或向量模式（不同异常跳转到不同偏移）。 - 异常原因：
scause寄存器记录异常类型。注意，S-mode只能看到与自己相关的异常——比如缺页、系统调用等。 - 异常值：
stval寄存器存放附加信息，比如缺页的虚拟地址。 - 返回机制：用
sret指令返回。它会从sepc中取出返回地址，并恢复sstatus中的SPP字段。
你想想看，为什么操作系统要用S-mode而不是M-mode？因为M-mode太“重”了——它没有虚拟内存的概念，而且所有异常都直接暴露给硬件。S-mode则提供了一个中间层，让操作系统可以优雅地管理进程、内存和系统调用。
避坑指南：我曾经在移植Linux到RISC-V FPGA时，发现S-mode的异常处理总是莫名其妙地触发M-mode的异常。查了半天，原来是stvec配置错了——我把向量表地址写成了M-mode的地址空间。记住：S-mode的异常向量必须在S-mode可访问的地址范围内，否则会触发“非法访问”异常，直接掉到M-mode。
4.3 用户模式（U-mode）—— 最受限，最安全
U-mode是给普通应用程序用的。它权限最低，不能直接访问硬件资源，也不能执行特权指令。说白了，U-mode就是“被管着”的模式。
U-mode的异常处理有个特点：它不能自己处理异常。所有在U-mode下发生的异常，都会“向上冒泡”——要么被S-mode捕获（如果有S-mode），要么直接掉到M-mode。
举个例子：
// U-mode下执行非法指令
// 处理器会：
// 1. 检查当前模式（U-mode）
// 2. 查看是否有S-mode（有的话，异常交给S-mode）
// 3. 如果没有S-mode，异常直接交给M-mode
// 4. 更新sepc或mepc，记录异常返回地址
// 5. 跳转到stvec或mtvec指向的处理程序U-mode的异常处理其实很简单——它不需要配置任何异常向量，也不需要处理任何异常。它只需要知道：一旦异常发生，控制权就交出去了。至于怎么处理，那是S-mode或M-mode的事。
关键点：U-mode下的异常处理，本质上是“委托”机制。RISC-V通过medeleg和mideleg寄存器，把一部分异常和中断委托给S-mode处理。这样M-mode就不用操心所有事情了。
4.4 三种模式的异常处理差异对比
咱们用一张表来总结一下：
| 特性 | M-mode | S-mode | U-mode |
|---|---|---|---|
| 异常向量寄存器 | mtvec | stvec | 无（依赖上级模式） |
| 异常原因寄存器 | mcause | scause | 无 |
| 异常值寄存器 | mtval | stval | 无 |
| 返回指令 | mret | sret | 无（由上级模式返回） |
| 返回地址寄存器 | mepc | sepc | 无 |
| 能否处理异常 | 能（所有异常） | 能（委托的异常） | 不能（必须委托） |
| 典型用途 | Bootloader、安全监控 | 操作系统内核 | 用户应用程序 |
4.5 异常委托机制——让M-mode“减负”
你可能会问：如果所有异常都交给M-mode处理，那M-mode岂不是忙死了？没错，所以RISC-V引入了异常委托机制。
通过medeleg寄存器，M-mode可以把某些异常委托给S-mode处理。比如系统调用（ecall指令）、缺页异常等。这样，M-mode只需要处理那些真正需要最高权限的异常（比如硬件错误、非法访问等）。
我在FPGA上实现时，习惯这样配置：
// 将系统调用和缺页异常委托给S-mode
// medeleg寄存器位定义：
// bit 8: 系统调用（U-mode）
// bit 9: 系统调用（S-mode）
// bit 12: 缺页异常（指令）
// bit 13: 缺页异常（数据读）
// bit 15: 缺页异常（数据写）
// 配置示例（汇编）：
li t0, (1 << 8) | (1 << 9) | (1 << 12) | (1 << 13) | (1 << 15)
csrw medeleg, t0个人习惯：我一般会把所有与操作系统相关的异常都委托给S-mode，只保留硬件错误和非法访问在M-mode。这样M-mode的异常处理程序可以非常精简，甚至只用几十条指令就能搞定。
4.6 异常处理流程对比——一张图看懂
下面这张SVG图展示了三种模式下异常处理的完整流程：
4.7 实践中的选择建议
最后，结合我在FPGA上的实际经验，给各位一些建议：
- 如果只做裸机程序：只用M-mode就够了。所有异常都在M-mode处理，简单直接。
- 如果要跑操作系统：必须实现S-mode。把系统调用、缺页等异常委托给S-mode，M-mode只处理硬件错误。
- 如果要跑多进程：U-mode是必须的。应用程序跑在U-mode，操作系统跑在S-mode，硬件监控跑在M-mode。
- 异常处理程序要精简：尤其是M-mode的handler，越短越好。我见过有人把M-mode的异常处理写成几百行C代码，结果调试起来痛不欲生。
再次提醒：在FPGA上调试异常处理时，一定要先确认mtvec和stvec的地址是否正确。我曾经因为地址对齐问题，浪费了整整两天时间。RISC-V要求异常向量地址按4字节对齐（直接模式）或按256字节对齐（向量模式），这个细节很容易被忽略。
好了，关于三种特权模式的异常处理差异，就聊到这里。记住一句话：M-mode兜底，S-mode管系统，U-mode只管跑。理解了这句话，你就掌握了RISC-V异常处理的精髓。