1月16日，玄鐵高級技術專家-郭任受邀參加2024東京RISC-V冬季會議，進行了主題名為《rv64ilp32: The future of 32-bit Linux》的演講。在計算機科學領域，選擇合適的指針位寬和指令架構對系統的性能和資源利用至關重要。本文將探討:

為何選擇 32位指針

為何選擇 64位指令架構

介紹玄鐵在RISC-V 64ilp32 ABI上的工作

為何選擇32位指針？

計算機科學巨擘、圖靈獎得主唐納德在2008年的博客中曾發表過一段著名的言論，他抱怨道：在編譯內存需求不足4GB的程序時，使用64位指針是非常不明智的。因為當這些指針值出現在結構體中時，它們不僅浪費了一半的內存，而且還導致一半的緩存被浪費。這表明，在不需64位尋址的情境中，使用64位指針不僅增加了內存消耗，還降低了緩存的使用效率。相比之下，使用32位指針可以更有效地利用內存和緩存資源，提高程序的性能。因此，唐納德的觀點強調了在不需要64位尋址的場景中，應優先選擇使用32位指針。

唐納德指出，不當地使用64位指針會導致內存的浪費。為了驗證這一觀點，我們進行了一項實驗，對比了rv64ilp32和rv64lp64 Linux內核的內存開銷。實驗環境基于Linux tinyconfig，并且啟動日志已進行逐行對齊，以確保兩種配置在軟件層面完全一致：

實驗結果顯示，64位指針相比32位指針浪費了高達25%的內存！對于許多嵌入式工程師而言，幾百KB的內存都是寶貴的資源，他們無法容忍這種浪費。因此，在不需要64位尋址的場景中，使用32位指針是更為明智的選擇，可以有效降低內存開銷。

唐納德還指出，不合理使用64位指針會導致緩存效率降低，進而影響性能。為了驗證這一觀點，我們對64ilp32和64lp64 SPEC2006的性能進行了對比。實驗結果如下：

黃色柱狀圖表示在Sifive Unmatched開發板上的測量結果。柱狀體向上表示32位指針相比64位指針的性能提升幅度，柱體向下表示性能下降幅度。

藍色柱狀圖表示在Allwinner D1開發板上的測量結果。

需要注意的是，由于rv64ilp32的編譯器仍處于開發階段，優化尚不完美，因此在456.hmmer測試用例中性能有所下降。經過分析，這是一個編譯器性能問題，未來將會得到解決。總體結果顯示，在相同的rv64指令架構的硬件上，使用32位指針相比64位指針可以顯著提升性能。這一結果進一步支持了唐納德的觀點，即在不需要64位尋址的場景中，使用32位指針是更明智的選擇，可以有效提升緩存利用率達到提升性能的目的。

在SPEC 2017測試中，我們進一步驗證了32位指針相比64位指針在性能上的優勢。實驗結果顯示，使用32位指針在多個測試用例中都獲得了顯著的性能提升。

32位指針在嵌入式系統中至關重要，通常人們會選擇傳統的32位指令架構。然而，近期情況發生了變化，許多嵌入式芯片制造商由 arm32 轉向了RISC-V 64位指令架構（Allwinner D1s, SOPHGO CV1800B 和 Bouffalo Lab BL808 ...）。

為什么會發生這樣的轉變？讓我們進入下一個主題：

為何選擇64位指令架構？

Gary Explains 在 YouTube 上發布了一段熱門的視頻，標題為“32-bits is DEAD!”。確實，從幾個關鍵現象中我們可以觀察到，32位指令架構正在從應用處理器中消失。

RISC-V 的應用處理器 profiles 自從 RVA20、RVA22 到 RVA23，包括 RVB23，都未曾采納過32位指令架構

Arm-v9 的應用處理器規范已移除了32位指令架構

x86-s 規范同樣也剔除了32位指令架構

以上現象揭示了一個趨勢，新一代應用處理器正在逐步淘汰32位指令架構。那么，究竟是什么原因導致了這一趨勢呢？我嘗試著尋找答案：

無論是基于Arm-v8還是x86架構的64位處理器，都保留了32位指令架構模式。這種模式將64位寄存器壓縮至32位使用，導致丟棄了寄存器的高32位。唐納德認為，浪費一半緩存和內存的行為是“absolutely idiotic”。那么，浪費一半的寄存器的行為又該如何評價呢？

寄存器作為計算機系統中寶貴的存儲部件，直接參與處理器流水線的執行單元運作，對性能起到關鍵作用。然而，為了兼容性，過去十幾年間，我們浪費了一半的寄存器資源。這一現象的根本原因是，無論是Arm還是x86都已建立了根深蒂固的傳統32位軟件生態，導致他們繼續沿用傳統32位。與這些傳統架構不同，RISC-V沒有32位歷史包袱，它的32位軟件生態還處于萌芽期，這恰好為矯正和優化提供了絕佳時機。rv64ilp32 ABI 正是瞄準這一機遇，旨在規避過去架構中出現的謬誤，為嵌入式RISC-V應用處理器提供更卓越的新32位解決方案，以替代已顯老舊的傳統32位架構，實現性能與成本的雙贏。

那么，扔掉一半寄存器究竟會有什么樣的后果？

我們在相同 RISC-V 64位架構的硬件上，對比 rv64ilp32 和 rv32ilp32 的 Linux 內核 memcpy/memload/memset 函數的性能。藍色柱狀圖代表 Allwinner D1硬件平臺，而橘色柱狀圖代表算能 sg2042 硬件平臺。rv64ilp32 相比 rv32ilp32 在所有測試用例上，都獲得了性能提升，尤其是在 sg2042 硬件平臺上，平均獲得了接近翻倍的性能提升，這得益于其內存控制器提供了充足的帶寬，而 D1 硬件平臺受限于內存帶寬，性能提升幅度雖不如 sg2042，但也非常顯著。測試結果告訴我們，64位指令架構相比32位在性能上有巨大優勢，因為它有效提升流水線的吞吐帶寬，就如同大炮的口徑，口徑越大威力越大。那么，用純32位指令架構設計芯片，能否降低芯片面積？

我們的同行 ARM 已經做過嘗試，Cortex-A32 就是從 Cortex-A35 裁剪64位模式僅保留32位模式而來，單核面積下降了 13%，乍聽起來不錯，但這 13%并不簡單，它還包含了調整位寬之外的其他變更：

AArch64 有 31 個寄存器，但 AArch32 只有 15 個，剔除了16個通用寄存器，這項修改所涉及的 bit 總數和改變通用寄存器位寬（從64位到32位）是一樣多的。

AArch64 有 32 個128位 SIMD 寄存器，但 AArch32 只有 16 個，又剔除16個 SIMD 寄存器，這項修改所涉及的 bit 總數是改變通用寄存器位寬的 4 倍。

Cortex-A35 是 AArch32 + AArch64 的結合體，并不是純 64位指令架構的處理器，但 Cortex-A32 只支持 AArch32，是純32位指令架構的處理器，所以這不是 AArch64 v.s. AArch32。

所以當我們將 13%換算到 RISC-V 上時，結合以上3個因素打一個折扣，13%/4=3.25%，而這僅僅是從單核的視角去思考。如果再從整個應用處理器 SoC 的維度看，當加上 L2 緩存、系統總線和各種 IP后，CPU核面積在整個應用處理器芯片的占比，不會超過 10%（一般小于5%）。綜上所述，使用 32 位指令架構能為整個 SoC 芯片面積帶來的收益，實在太小了！讓我們再回顧下這些小內存應用處理器芯片：

這些廠商選擇 RISC-V 64位指令架構替換 arm32 是有遠見且明智的，他們在用真金白銀的行動告訴我們，RISC-V 64位指令架構才是 32位Linux 的未來！而我們的工作就是實現 rv64ilp32 ABI，在 RISC-V 64位指令架構上完美運行 32位 Linux：

玄鐵在RISC-V 64ilp32 ABI上的工作

實現 rv64ilp32 意味著引入了一個全新的ABI，這是一個龐大的工程，需要大量的投入來推動整個軟件生態的發展。盡管有人因為畏懼挑戰而猶豫不前，甚至將這種情緒蔓延到整個Linux世界，認為x86-x32、mips-n32和arm64-ilp32都失敗了，憑什么RISC-V會成功。但我對此不以為然。這些架構之所以失敗，是因為它們的32位ABI根深蒂固，難以改變。如果人們想要使用32位指針，只需讓硬件在32位模式下運行現有的軟件即可。然而，RISC-V的32位軟件生態尚處于萌芽階段，沒有歷史包袱。

我們汲取了前人的經驗，并在此基礎上進行了創新。在實現了用戶態u64ilp32 ABI的基礎上，我們首次實現了s64ilp32 Linux內核，并以嵌入式小內存場景為切入點，使其更貼近實際應用場景（而非x86-x32的科學計算和基準測試場景）。

我們為Linux內核實現了36個補丁：

前11個補丁是 u64ilp32 用戶態支持，而X86、MIPS和ARM也僅實現了這一步。

后25個補丁是 s64ilp32 Linux內核，即讓32位Linux完美運行在64位指令架構的硬件上，是世界上第一個 64ilp32 ABI 的 Linux 內核。

上圖中展示：該補丁集為Linux引入了新的內核模式s64ilp32，該模式同時支持u64ilp32和u32ilp32兩種用戶態ABI。

此外，該補丁集還為s64lp64內核模式增加了對u64ilp32用戶態ABI的支持。

相較于傳統的s32ilp32內核，新的s64ilp32內核具有以下優勢：

內核的內存拷貝函數性能大幅提升。

ebpf JIT性能大幅領先。

支持原生64位原子指令。

支持原生64位算術指令。

目前，我們已初步完成Fedora 38的移植工作：

由于構建u64ilp32用戶態的道路漫長，我們決定先采用s64ilp32+u32ilp32的混合模式，以快速交付完整的32位Linux解決方案。該方案可在配備玄鐵c908和c907的芯片上運行，這些處理器都支持sxl=64 uxl=32的混合模式。此項工作由三個團隊共同完成：

PLCT團隊負責編譯器和工具鏈的開發。

玄鐵處理器團隊負責Linux內核和CPU的適配工作。

Fedora團隊則負責Linux發行版的構建與維護。

由于RISC-V的32位軟件生態相對薄弱，我們開創性地引入了兼容u64lp64的模式：

使64位應用程序得以在32位Linux內核上運行。我們已經完成了原型驗證，成功將64位地址空間壓縮至2GB，并順利啟動了整個64位根文件系統。這一創新特性將作為下一版本[RFC PATCH V3]的重要組成部分，旨在彌補RISC-V在32位軟件生態方面的不足。在完成“s64ilp32 + u64lp64”特性后，我們進一步統一了s64ilp32和s64lp64支持的用戶態模式，實現了根文件系統的二進制兼容性：

這意味著在這兩種模式下，應用程序和操作系統可以無縫地運行，無需進行額外的修改或適配。這一改進不僅簡化了軟件開發和部署過程，還增強了RISC-V架構的靈活性和可擴展性。我們的最終目標是，通過實現“s64ilp32 + u64ilp32”的組合取代傳統32位，并復用64位的系統調用接口，刪除老32位，實現Linux用戶ABI的統一：

這將有助于簡化軟件的開發、部署和維護過程，提高系統的穩定性和兼容性。RISC-V 64ilp32 ABI 也將進一步推動RISC-V架構的發展和普及，使其成為更多應用領域的理想選擇。

Linux CPU子系統的維護者 Arnd Bergmann 曾寫過一篇同名文章 "The future of 32-bit Linux"，文中他詳細分析了當前32位Linux的歷史和現狀，給出了一個不幸的結論：等 arm32 退出歷史舞臺，32位Linux就會消亡。然而，我們認為rv64ilp32 ABI 將進一步推動玄鐵 RISC-V 在嵌入式 Linux 領域的商業化進程，并有望取代 Arm32 架構，為32位Linux開創一個光明的未來。