exception - RISC-V SYSTEM 指令如何实现为陷阱？

Question

我目前正在研究具有规范版本 2.2 和特权架构版本 1.10 的 RISC-V 规范。在 RISC-V 规范的第 2 章中，提到“[...] 尽管一个简单的实现可能涵盖了八个 SCALL/SBREAK/CSRR* 指令，其中一条 SYSTEM 硬件指令总是捕获 [...]”
但是，当我查看特权规范时，指令 MRET也是 SYSTEM 指令，需要从陷阱返回。现在我很困惑需要多少机器级 ISA:是否可以省略所有 M 级 CSR 并为任何系统指令使用软件处理程序，如规范中所述？如果是这样，如何传入返回地址和陷阱原因等信息？它们是通过常规寄存器 x1-x31 完成的吗？
或者，如果我的目标是一个只有 M 级特权的简单嵌入式内核，仅实现以下 M 级 CSR 就足够了吗？

mvendorid
marchid
mimpid
mhartid
misa
mscratch
mepc
mcause

最后，这些CSR中有多少可以省略？

Answer 1

ECALL/EBREAK 指令无论如何都是陷阱。 CSR 指令需要仔细解析，以确保它们指定在允许的模式下访问的现有寄存器，这听起来像是您最喜欢的稀疏矩阵的工作，无论是 PLA 还是 if/then。

您可以模拟所有 SYSTEM 指令，但是，如您所见，您需要能够访问不属于正常 ISA 的硬件内部的信息。这意味着您需要添加“指令扩展”。

我还建议使 SYSTEM 指令原子化，这意味着应该在每个模拟指令中屏蔽或避免异常。

由于我不是一个非常信任的人，因此我将创建一种新模式，该模式将启用指令扩展，例如，允许您直接从硬件读取异常地址，并从 protected 内存区域获取指令。中断将被自动禁用。该模式将通过跳转到 epc+4 或非法指令处理程序退出。为了安全起见，即使在 M 模式下，我也不希望 RISC-V 规范之外的任何东西可用。

根据我的经验，与其向每个客户解释，不如说“我做所有事情”，或者更糟的是，让竞争对手向您的客户解释您没有做什么。但也许更了解 CSR 的人可以提供帮助；这不是我做的事情。