| RFC-0234：更新 RISC-V ABI：RVA22 + V | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 將 Fuchsia 的 RISC-V ABI 更新為 RVA22 + V |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-11-02 |
| 審查日期 (年-月-日) | 2023-11-17 |
摘要
我們建議更新 RISC-V ABI，改用 RVA22{U,S}64 設定檔，並新增對向量擴充功能 (V) 的支援。
提振精神
RVA22 代表 RISC-V International 基金會的產業共識，為鎖定應用程式層級處理器的硬體和軟體，提供合理的基準概念。由於新一代 RISC-V 硬體預期會廣泛支援 RVA22，且 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
審查者：
- phosek@google.com (Toolchain)
- travisg@google.com (Kernel)
設計
設計時的一項重要考量是，在管理及公開向量暫存器的狀態時，如何處理向量暫存器的可變長度特性：如規格所述，每個向量暫存器的長度範圍為 16 位元組到 8 KiB，因此向量狀態的總大小範圍為 1/2 KiB 位元組到 256 KiB。不過，由於可預見的向量擴充功能實作項目僅限於 16 位元組長度，因此我們現在可以做出簡化假設，也就是這些項目長度正好為 16 位元組，並暫時忽略變異性。
除此之外，幸好需要設計的部分不多。Clang、GCC 和 rustc 已支援相關 ISA 擴充功能，只要進行簡單的建構變更，即可選擇啟用。核心支援會遵循預先建立的模式來處理浮點/向量狀態，與本提案無關。
實作
- 我們的 QEMU 命令列會更新，選擇模擬新的指令和功能。
- 只要進行簡單的建構變更，將
fuchsia_riscv_profile = riscv_profiles.rva22設為 here，RVA22 就會成為新的 ABI。 - 我們會一併新增核心支援功能，以便儲存向量暫存器狀態，再次擴充 ABI 並支援 V。
zx_thread_read_state(..., ZX_THREAD_STATE_VECTOR_REGS,...)的 RISC-V 版本將更新為傳回三十二個 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 為目標平台時，不必額外負擔 (因為 Fuchsia 提供的功能與其他作業系統相同) 的便利性。但我們不知道相關硬體平台和應用程式生態系統最終會採用哪種做法。在此之前，RVA22 (目前這一代的設定檔) 搭配 V (即將強制執行的擴充功能，可啟用基本運算模式) 似乎是不錯的下一個基準。
稍微簡單的替代方案是強制使用 RVA22。不過如上所述，堅持採用單一 RISC-V 標準，很快就會在 RVA23 中導入 V。如果選擇支援 V，我們也需要在核心和使用者空間中導入新支援，以進行功能偵測和執行階段切換，這種做法會以執行階段複雜度換取更廣泛的硬體支援。
既有技術和參考資料
Android 正在暫時設定其 ABI 為 RVA22 + V，以及一些向量加密擴充功能。