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 國際基金會的業界共識，在指定應用程式層級處理器時，可提供目前合理基準的概念，無論是硬體或軟體都適用。考量到新一代 RISC-V 硬體預期會廣泛支援，以及 Fuchsia 尚未正式採用上一代任何硬體的支援，因此 Fuchsia 目前採用 RVA22 的門檻較低。

我們先前曾說明，在 RFC-0211 中，我們之所以採用 RVA20{U,S}64 的初始暫時採用方式，是因為在 RISC-V 的早期硬體前支援階段，QEMU 是我們唯一的官方目標，因此我們仍處於該階段，而 QEMU 目前支援額外的 RVA22 擴充功能，因此這裡的考量應該也類似。

雖然向量擴充功能 (V) 在 RVA22 中為選用，但在 RVA23 中為必用，因此很快就會再次套用上述邏輯。此外，擴充功能必須與我們支援的架構保持一致。在 x86-64 上，我們支援 SSE 和 AVX2 擴充功能；在 arm64 上，我們支援 ASIMD(/NEON) 擴充功能；相較之下，V 是對應的 RISC-V 擴充功能，但我們不支援該擴充功能。SIMD/向量擴充功能對於以任何合理精確度支援實際工作負載 (例如圖形) 也至關重要。

相關人員

講師：jamesr@google.com

審查者：

  • phosek@google.com (工具鍊)
  • 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 這裡，即可透過簡單的建構變更，將 RVA22 設為新的 ABI。
  • 使用 V 支援功能再次擴充 ABI 時，請一併新增可儲存向量註冊狀態的核心支援功能。
  • 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 核心測試，證明為了在多個情境切換中執行的向量運算，會產生預期的值。這間接證明核心會在切換情境時儲存相關的向量狀態。

說明文件

目前的先例 (由過去的 RFC 設定，這些 RFC 已定義或更新了特定架構的 ABI) 是，此 RFC 本身可做為已記錄的基準。

缺點、替代方案和未知事項

我們正試圖在以下兩者之間取得平衡：Fuchsia 採用更多硬體平台的便利性 (透過減少功能要求)，以及應用程式開發人員以 Fuchsia 為目標平台的便利性 (透過提供與其他作業系統相同的功能)，而不會增加額外負擔。不過，我們不清楚相關硬體平台和應用程式生態系統最終會採用哪些技術。在此之前，RVA22 (目前的世代設定檔) 搭配 V (即將成為強制擴充功能，可啟用基本運算模式)，似乎不是下一個基準的明智選擇。

比較簡單的做法是強制使用 RVA22。不過，如上所述，如果想採用單一 RISC-V 標準，很快就會透過 RVA23 實現 V。在提供 V 選用支援的情況下，我們也需要在核心和使用者空間中引入新的支援功能，以便偵測功能和執行階段切換，這種做法可在執行階段複雜度方面提供更廣泛的硬體支援。

既有技術與參考資料

Android 目前正在(暫時) 設定 ABI 為 RVA22 + V，以及一些向量加密擴充功能。