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 Foundation 的行业共识，为定位应用级处理器的硬件和软件提供了当前合理的基准构想。鉴于新一代 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/矢量扩展也至关重要。

利益相关方

主持人：jamesr@google.com

Reviewers:

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

设计

设计的一个重要方面是，在管理和公开矢量寄存器状态时，我们如何处理矢量寄存器的可变长度特性：根据规范，每个矢量寄存器的长度均介于 16 字节到 8 KiB 之间，这使得矢量状态的总大小介于 1/2 KiB 字节到 256 KiB 之间。不过，由于可预见的向量扩展实现的长度限制为 16 个字节，因此我们可以暂时假设它们的长度恰好为 16 个字节，并推迟考虑可变性。

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

实现

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

性能

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

允许编译器发出矢量指令应该会带来净性能提升（信任编译器启发词语，随着时间的推移，性能应该会得到提升）。

虽然我们通过保存矢量状态延长了每个上下文切换中完成的工作量，但这只会导致复制 512 字节，并且我们提供了一些简单的优化，以便在线程未修改矢量状态时避免此复制（这可能经常发生）。

工效学设计

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

向后兼容性

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

安全注意事项

不适用

隐私注意事项

不适用

测试

我们将添加一个 Zircon 核心测试，以证明经过编排在多个上下文切换中执行的矢量计算将产生预期值。这间接证明了内核会在上下文切换期间保存相关的矢量状态。

文档

当前的先例（由定义或提升了架构专用 ABI 的过往 RFC 设定）是，此 RFC 本身可用作记录的基准。

缺点、替代方案和未知情况

我们正努力在以下两方面取得平衡：一方面，通过强制要求提供更少的功能，让 Fuchsia 能够更轻松地采用更多种类的硬件平台；另一方面，通过提供与其他操作系统相同的功能，让应用开发者能够在不增加额外负担的情况下以 Fuchsia 为目标平台。不过，我们尚不清楚相关硬件平台和应用生态系统最终会采用什么方案。在此之前，RVA22（当前一代配置文件）与 V（即将成为强制性扩展，可启用基本计算模式）的组合似乎不是一个不谨慎的下一个基准。

一个稍微简单的替代方案是强制使用 RVA22。不过，正如前面所提到的，如果希望坚持使用单一 RISC-V 标准，那么很快就会使用 RVA23 来表示 V。在支持可选 V 的情况下，我们还需要在内核和用户空间中引入新的支持，以实现功能检测和运行时切换。这种方法会以更广泛的硬件支持为代价来换取运行时复杂性。

在先技术和参考文档

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