| RFC-0234：更新 RISC-V ABI：RVA22 + V | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 将 Fuchsia 的 RISC-V ABI 更新为 RVA22 + V |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-11-02 |
| 审核日期（年-月-日） | 2023-11-17 |
总结
我们在此建议更新由 RVA22{U,S}64 配置文件提供的 RISC-V ABI，并添加对矢量扩展 (V) 的支持。
设计初衷
RVA22 通过 RISC-V International 基金会代表行业共识，给出了当以应用级处理器为目标时，对于硬件和软件等而言，当前概念是合理的基准。考虑到新一代 RISC-V 硬件将获得广泛支持，而且 Fuchsia 尚未正式采用对上一代中的任何硬件的支持，因此目前对 Fuchsia 采用 RVA22 的标准并不高。
我们之前在 RFC-0211 中最初临时采用 RVA20{U,S}64 的原因是：QEMU（我们唯一的官方目标）在 RISC-V 的早期硬件前支持阶段支持 RVA20{U,S}64；因此，我们仍然处于该阶段，因此 QEMU 现在支持额外的扩展，
虽然矢量扩展 (V) 在 RVA22 中是可选的，但已设置为 RVA23 中的必需项，因此上述逻辑很快将再次适用。此外，为了达到我们支持的架构的要求，需要扩展。 在 x86-64 上，我们支持 SSE 和 AVX2 扩展；在 arm64 上，我们支持 ASIMD(/NEON) 扩展；相比之下，V 是对应的 RISC-V 扩展，但我们缺乏对它的支持。SIMD/矢量扩展对于以任何合理的保真度支持实际工作负载（例如图形）也至关重要。
利益相关方
教员：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，只需进行简单的 build 更改，即可将 RVA22 设置为新的 ABI。 - 通过添加 V 支持再次扩展 ABI，会同时添加针对保存矢量寄存器状态的内核支持。
- RISC-V 的
zx_thread_read_state(..., ZX_THREAD_STATE_VECTOR_REGS,...)将更新以返回 32 个 16 字节的矢量寄存器内容（此时调试程序可能会开始添加自己的支持）。 - 稳定后，我们将更改 Clang 编译器驱动程序，为
riscv64-fuchsia目标使用默认的-march值，该值与新 ABI 匹配（将更改传播给 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，以及一些矢量加密扩展。