如何保持 RISC-V 合规性？
How do I keep RISC-V compliance?
我刚刚与一位同事讨论了 RISC-V 合规性的实际含义。我们详细讨论了以下主题：
据我了解，只要处理器实现了 RISC-V 基本指令集和可选的一个或多个标准扩展，它就是 RISC-V 兼容的。 完全，不只是部分。只要不触及基本指令集或任何标准扩展，甚至可以定义和实现自己的指令（如棕地或绿地扩展）。为了保证这一点，任何符合 RISC-V 标准的编译器生成的机器码都会在我的机器上 运行 。这就是重点，对吧？
RISC-V ISA 不打算延迟分支。我的理解是，分支是否延迟的定义已经是 ISA 的一部分，而不是实施问题。这是正确的吗？
假设一个人想要使用带有延迟分支的 RISC-V。不管这是不是一个好主意，让我们只关注合规性问题。在我看来，将 基本指令集 的一些现有 branch/jump 指令定义和实现为延迟分支不再符合 RISC-V。 RISC-V 兼容编译器的编译将不再适用于这样的机器。可以自由定义 own 延迟分支指令。当然，与任何自写扩展一样，不能指望任意编译器会使用这样的指令。我说的对吗？
根据RISC-V规范，"the program counter pc holds the address of the current instruction."我对这句话的解释是，任何jump/branch指令指的是它存放的地址。同样，独立于实施。示例：假设 jump/branch 指令在被提取后执行几个周期的实现。这意味着 PC 可能已经增加了。因此，实现的任务是以某种方式存储 jump/branch 指令的地址。 不是 编译器的任务是了解此延迟并通过修改要添加到 PC 的立即数来补偿它。我的总结是否正确？
所以，简而言之，我的问题的简短版本：
RISC-V 合规性是否意味着基本整数指令集和标准扩展不得更改或剥离？
分支是否延迟的信息是否已经是ISA的一部分？
RISC-V 的 PC 是否被认为不受任何管道延迟的影响？
我认为 ISA 通常与任何实现细节无关。与我所声称的相反的论点是，人们必须告诉编译器有关实现细节（延迟分支、PC 行为等）并且这仍然可以被认为符合 ISA。
我不是专家，但在过去 20 年中实现了几个核心。您的三个部分问题中的关键概念是 完整性 和 用户可见性。在我看来，声称完整性意味着不能更改或删除标准的任何部分。然而，如果它没有可疑的点和可能被不同人解释不同的部分，那确实是一个难得的标准。在 RISC-V 的特定情况下，如果您还没有看到它，我想指出对 indicate compliance 的帮助。
如果有真正的专家来回答这个问题就好了。
- Does RISC-V compliance mean that base integer instruction set and standard extension must neither be changed nor stripped?
我的理解和你一样。声明标准中定义的行为然后不遵守该标准是没有意义的。
- Is the information whether a branch is delayed or not already part of the ISA?
我再次同意你的看法。延迟分支是处理器用户的公开功能。因此，ISA 必须指定此类分支的最终存在，事实上，从 riscv-spec-v2.2.pdf:
的第 15 页开始
"Control transfer instructions in RV32I do not have architecturally visible delay slots."
注意措辞，只要您的实现不向用户暴露任何延迟槽，您就可以随心所欲。使用非标准扩展，您可以完全自由地设计具有延迟槽的指令，您甚至可以将 RV32I 指令放入这些槽中。
- Is the PC of RISC-V considered agnostic to any pipeline delay?
是的。
我刚刚与一位同事讨论了 RISC-V 合规性的实际含义。我们详细讨论了以下主题：
据我了解，只要处理器实现了 RISC-V 基本指令集和可选的一个或多个标准扩展，它就是 RISC-V 兼容的。 完全，不只是部分。只要不触及基本指令集或任何标准扩展，甚至可以定义和实现自己的指令（如棕地或绿地扩展）。为了保证这一点，任何符合 RISC-V 标准的编译器生成的机器码都会在我的机器上 运行 。这就是重点，对吧？
RISC-V ISA 不打算延迟分支。我的理解是，分支是否延迟的定义已经是 ISA 的一部分，而不是实施问题。这是正确的吗？
假设一个人想要使用带有延迟分支的 RISC-V。不管这是不是一个好主意，让我们只关注合规性问题。在我看来，将 基本指令集 的一些现有 branch/jump 指令定义和实现为延迟分支不再符合 RISC-V。 RISC-V 兼容编译器的编译将不再适用于这样的机器。可以自由定义 own 延迟分支指令。当然，与任何自写扩展一样，不能指望任意编译器会使用这样的指令。我说的对吗？
根据RISC-V规范，"the program counter pc holds the address of the current instruction."我对这句话的解释是，任何jump/branch指令指的是它存放的地址。同样，独立于实施。示例：假设 jump/branch 指令在被提取后执行几个周期的实现。这意味着 PC 可能已经增加了。因此，实现的任务是以某种方式存储 jump/branch 指令的地址。 不是 编译器的任务是了解此延迟并通过修改要添加到 PC 的立即数来补偿它。我的总结是否正确？
所以，简而言之，我的问题的简短版本：
RISC-V 合规性是否意味着基本整数指令集和标准扩展不得更改或剥离？
分支是否延迟的信息是否已经是ISA的一部分？
RISC-V 的 PC 是否被认为不受任何管道延迟的影响？
我认为 ISA 通常与任何实现细节无关。与我所声称的相反的论点是，人们必须告诉编译器有关实现细节（延迟分支、PC 行为等）并且这仍然可以被认为符合 ISA。
我不是专家，但在过去 20 年中实现了几个核心。您的三个部分问题中的关键概念是 完整性 和 用户可见性。在我看来，声称完整性意味着不能更改或删除标准的任何部分。然而，如果它没有可疑的点和可能被不同人解释不同的部分，那确实是一个难得的标准。在 RISC-V 的特定情况下，如果您还没有看到它，我想指出对 indicate compliance 的帮助。
如果有真正的专家来回答这个问题就好了。
- Does RISC-V compliance mean that base integer instruction set and standard extension must neither be changed nor stripped?
我的理解和你一样。声明标准中定义的行为然后不遵守该标准是没有意义的。
- Is the information whether a branch is delayed or not already part of the ISA?
我再次同意你的看法。延迟分支是处理器用户的公开功能。因此，ISA 必须指定此类分支的最终存在，事实上，从 riscv-spec-v2.2.pdf:
的第 15 页开始"Control transfer instructions in RV32I do not have architecturally visible delay slots."
注意措辞，只要您的实现不向用户暴露任何延迟槽，您就可以随心所欲。使用非标准扩展，您可以完全自由地设计具有延迟槽的指令，您甚至可以将 RV32I 指令放入这些槽中。
- Is the PC of RISC-V considered agnostic to any pipeline delay?
是的。