RFC-0234：更新 RISC-V ABI：RVA22 + V

RFC-0234：更新 RISC-V ABI：RVA22 + V
状态已接受
区域
  • 内核
  • 工具链
说明

将 Fuchsia 的 RISC-V ABI 更新为 RVA22 + V
Gerrit 更改
作者
审核人
提交日期（年-月-日）2023-11-02
审核日期（年-月-日）2023-11-17

修改此 RFC

修改 RFC 元数据

摘要

在此，我们建议更新 RISC-V ABI，使其由 RVA22{U,S}64 配置文件提供，并添加对矢量扩展 (V) 的支持。

设计初衷

RVA22 通过 RISC-V International 基金会代表行业共识，在面向应用级处理器时，为硬件和软件提供合理的基准。鉴于新兴一代 RISC-V 硬件有望得到广泛支持，并且 Fuchsia 尚未正式采用对上一代任何硬件的支持，因此 Fuchsia 目前采用 RVA22 的门槛较低。

我们之前在 RFC-0211 中初步临时采用 RVA20{U,S}64 的理由是，在 RISC-V 的早期硬件支持前阶段，QEMU（我们唯一的官方目标）支持该指令集；因此，我们目前仍处于该阶段，而 QEMU 现在支持额外的 RVA22 扩展，因此此处的考虑因素应类似。

虽然在 RVA22 中，向量扩展 (V) 是可选的，但它将被设置为在 RVA23 中强制使用，因此上述相同逻辑很快将再次适用。此外，为了与我们支持的架构保持一致，还需要该扩展程序。在 x86-64 上，我们支持 SSE 和 AVX2 扩展；在 arm64 上，我们支持 ASIMD(/NEON) 扩展；相比之下，V 是相应的 RISC-V 扩展，但我们不支持它。SIMD/向量扩展对于以任何合理的保真度支持实际工作负载（例如，用于图形）也至关重要。

利益相关方

Facilitator: jamesr@google.com

审核者：

  • phosek@google.com （工具链）
  • travisg@google.com （内核）

设计

设计方面的一个重要点是，在管理和公开向量寄存器的状态时，我们如何处理其可变长度的特性：根据规范，每个向量寄存器的长度范围为 16 字节到 8KiB，这使得向量状态的总大小范围为 1/2 KiB 字节到 256 KiB。不过，由于可预见的向量扩展程序实现仅限于 16 字节长度，因此我们可以暂时做出简化假设，即它们正好是 16 字节长度，并暂时忽略可变性。

除此之外，幸运的是，几乎不需要进行设计。Clang、GCC 和 rustc 已经支持相关 ISA 扩展，选择启用这些扩展只需进行简单的 build 更改。内核支持将遵循其预先建立的浮点/向量状态处理模式，与本提案无关。

实现

  • 我们将更新 QEMU 命令行，以选择模拟新的指令和功能。
  • 通过设置fuchsia_riscv_profile = riscv_profiles.rva22 此处，RVA22 将设置为新的 ABI，只需进行简单的 build 更改即可。
  • 再次扩展 ABI 以支持 V 将与添加内核支持以保存向量寄存器状态相结合。
  • RISC-V 的 zx_thread_read_state(..., ZX_THREAD_STATE_VECTOR_REGS,...) 将更新为返回 32 个 16 字节的矢量寄存器内容（此时调试器可以开始添加自己的支持）。
  • 稳定后，我们将更改 Clang 编译器驱动程序，以便为与新 ABI 相匹配的 riscv64-fuchsia 目标使用默认 -march 值（将更改传播给 Fuchsia 的所有用户，而不仅仅是那些在平台构建系统内操作的用户）。

性能

在 Zb{a,b,s} 中添加的位操作指令应能减少指令数量，并加速大量基本算术运算。

允许编译器发出矢量指令应该会带来性能的净提升（相信编译器启发式方法，随着时间的推移，这种方法只会越来越好）。

虽然我们通过保存矢量状态延长了每次上下文切换时完成的工作量，但这只会复制 512 字节，并且我们提供了简单的优化措施，可在线程不修改矢量状态时避免此复制操作（这种情况可能很常见）。

工效学设计

此提案避免了在内核和 vDSO 中有条件地实现缓存维护（由 Zicbo{m,p,z} 提供），以及在用户空间中围绕手动调整的矢量例程进行运行时选择。

向后兼容性

提议的 ABI 更改只是添加性的（我们目前不处理分布式 RISC-V 软件），因此这方面没有问题。

安全注意事项

不适用

隐私注意事项

不适用

测试

将添加一个 Zircon 核心测试，以演示精心设计的在多次上下文切换中执行的向量计算将产生预期值。这间接表明，内核会在上下文切换期间保存相关的矢量状态。

文档

目前的先例（由定义或升级了特定于架构的 ABI 的过往 RFC 设定）是，此 RFC 本身就是记录在案的基准。

缺点、替代方案和未知因素

我们正在努力在以下两方面之间取得平衡：Fuchsia 通过强制要求更少的功能，从而能够更方便地采用各种硬件平台；应用开发者通过提供与其他操作系统相同的功能，从而能够更方便地以 Fuchsia 为目标平台，而无需承担额外的负担。不过，我们并不知道相关的硬件平台和应用生态系统最终会选择哪种。在此之前，具有 V（一种即将强制执行的扩展，可实现基本的计算模式）的 RVA22（当前一代配置文件）似乎是一个明智的下一个基准。

一种稍微简单一些的替代方案是强制使用 RVA22。不过，如上所述，坚持使用单一 RISC-V 标准的愿望很快就会随着 RVA23 的推出而实现 V。如果支持可选的 V，我们还需要在内核和用户空间中引入新的支持，以实现功能检测和运行时切换，这种方法会牺牲更广泛的硬件支持来换取运行时复杂性。

在先技术和参考资料

Android 正在（暂时）将其 ABI 设置为 RVA22 + V，以及一些矢量加密扩展。