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

RFC-0234：更新 RISC-V ABI：RVA22 + V
狀態已接受
區域
  • 核心
  • 工具鏈
說明

將 Fuchsia 的 RISC-V ABI 更新至 RVA22 + V
變更
  • 940906
作者
審查人員
提交日期 (年/月)2023-11-02
審查日期 (年/月)2023-11-17

編輯此 RFC

編輯 RFC 中繼資料

摘要

在此我們提議更新 RISC-V ABI，以便由 RVA22{U,S}64 設定檔提供，並新增對 Vector 擴充套件 (V) 的支援。

提振精神

以 RISC-V 國際基金會表示，RVA22 代表了業界共識，因此現在以硬體和軟體來說，指定應用程式層級處理器時，是獲得合理基準的合理概念。由於預期新興的 RISC-V 硬體支援廣泛支援，而且 Fuchsia 在最後一代尚未正式支援任何硬體，因此此時的 Fuchsia 採用 RVA22 的門檻較低。

我們先前針對 RFC-0211 中首次臨時採用 RVA20{U,S}64 的理由，就是其獲得 QEMU 的正式支援。在早期的正式硬體支援階段中，RISC-V 的硬體預先支援階段已提供支援。因此，我們現在仍應考慮到這個階段，而 QEMU 也因此應支援其他類似的擴充功能。

雖然 Vector 擴充功能 (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 擴充功能，並可採用與啟用金額簡易的建構異動。核心支援將遵循預設模式來處理浮點/向量狀態，且在本提案中並無實質內容。

實作

  • 系統會更新 QEMU 指令列，以選擇模擬新的操作說明和功能。
  • 系統會將 RVA22 設為新的 ABI，其建構方式十分簡易，只要在 fuchsia_riscv_profile = riscv_profiles.rva22 這裡設定即可。
  • 透過 V 支援再次擴充 ABI，也會新增核心支援來儲存向量註冊狀態。
  • RISC-V 的 zx_thread_read_state(..., ZX_THREAD_STATE_VECTOR_REGS,...) 將更新，以傳回三十二、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 產品。但我們不知道相關的硬體平台和應用程式生態系統最終究竟願意為何。在此之前，具備 V (啟用基本計算模式的必要擴充功能) 的 RVA22 (目前產生設定檔) 似乎不像下一個基準。

另一個更簡單的替代方案就是要求 RVA22。然而，如上所述，渴望採用單一 RISC-V 標準的做法已經顯然已經夠用 RVA23。採用選用的 V 支援後，我們還需要在核心和使用者空間中引入新的支援功能，以便進行特徵偵測和執行階段切換，這種方法可以排除較廣泛的硬體支援，降低執行階段複雜度。

先前的圖片和參考資料

Android 正在 (暫定) 將 ABI 設定為 RVA22 + V，以及部分 Vector Crypto 擴充功能。