RFC-0030:FIDL 為 little endian | |
---|---|
狀態 | 已接受 |
區域 |
|
說明 | 宣告 FIDL 是 little endian。 |
作者 | |
提交日期 (年-月-日) | 2019-01-30 |
審查日期 (年-月-日) | 2019-01-30 |
摘要
宣告 FIDL 是 little endian。
提振精神
透過指定可移植的位元順序,讓 FIDL 更接近可持久化格式。
初始設計特別選擇主機記憶體順序 (和表示法),以免在傳輸期間需要交錯記憶體。這是安全地將 FIDL 訊息表示為 C 結構體的關鍵。不過,我們也瞭解在近期內,在 big-endian 機器上執行 Fuchsia 的可能性不大,因此將 FIDL 設為 little-endian 是實際可行的決定。
設計
目前 FIDL 的說明文件使用主機位元順序,但所有現存的主機都是小端序。為了朝著可序列化的 FIDL 子集邁進,我們建議目前宣告 FIDL 為小端序 (這相當於說明文件的清理作業)。
如果我們需要支援 big endian 平台,就必須更新許多其他程式碼和文件,因此建議在那時處理 FIDL 的任何變更。
導入策略
準備 CL 來變更 FIDL 文件。
擷取預期值,即繫結僅用於小端機器,並做為程式碼中的斷言。
人體工學
人體工學未變更。
說明文件和範例
僅限規格變更。
回溯相容性
目前沒有變更。將限制 FIDL 在未來大端序裝置上執行 swizzling 的情況 (針對已儲存資料結構的情況最少)。
成效
目前的效能不會有任何變動。如果我們要支援大端字平台,可能需要修訂 FIDL。
安全性
安全性不會有任何變動。
測試
測試作業不變。
缺點、替代方案和未知事項
有兩個主要替代方案:
- 不提供可序列化功能,但這會限制 FIDL 在某些用途中的適用性。
- 提供可獨立儲存的格式,但這會導致需要在所有地方支援次要序列化路徑。
附加條款
雖然將 FIDL 修正為小端序的技術決策並未引起太多爭議,但和許多事情一樣,這項決策也引發了長篇執行緒。在本課程中,我們學到:
MIPS 會根據您在處理器復位後送入處理器的初始向量,同時執行 BE 和 LE (在 MIPS 還重要,且您可以購買獨立 MIPS CPU 的很久以前)。部分產品甚至會在重新啟動時切換字節順序 (請勿詢問原因)。
雖然 MIPS 已不再是主要的技術,但我們預期閘會會嵌入 SoC,且字節序可能會固定 (且可能會固定為 little)。
所有 ARM 核心都會實作大端序和小端序。
arm64 可在 SCTLR 中依 EL 選取。您可以在例外層級轉換時切換字節序模式。
arm(32) 會透過 SETEND 指令進行選取。它可以在執行階段的任何時間切換字節順序。您的編譯器不太可能支援這項功能,但對於某些手動編碼的彙整作業來說,這項功能可能很實用。
IEEE 802.11 是小端序:802.11 流量的管理和控制層會在其欄位中使用小端序。所有封裝的通訊協定仍為大端序,而 802.11 堆疊幾乎不處理大端序。
歷史記錄可追溯至 1982 年,當時 Xerox 發明瞭乙太網路。WLAN 大多會繼承這項決定。選擇 Little Endian 的原因?這是任意選擇:
「以太網路本身也完全不介意如何解讀位元組中的位元,以構成 8 位元二進位數值的數字。不過,由於某些統一慣例有助於避免不同站台類型之間出現不必要的不相容性,因此解讀方式是「任意定義」為以太網規格:資料連結層而言,最左邊位元 (最先傳送) 為低位元 (2^0) 位數,最右邊位元 (最後傳送) 為高位元 (2^7) 位數。
USB 是 little endian。
小知識:MAC 位址不會受到位元組排序的影響,但如果位址是 big-endian,您肯定可以在 IP 路由例程中減少幾個週期...甚至可以啟動較低延遲的「切換」路由,讓封包逐漸傳入,在古老的 ~1 Mbps 連結上逐位元組傳入 (每毫秒 ~128 位元組)。
有趣的事實:FAT 檔案系統會在標頭中使用小端序,但並非所有項目都採用。如果整個 FAT 開機區塊的檢查和總和碼以大端優先方式讀取為 0x1234,則 FAT 檔案系統可用於 Atari ST 上的 m68k 處理器可啟動裝置,這表示目前的年份實際上仍為 1985 年。
趣味小知識:還有中 endian,這是標準 GCC 定義的,並附註:
「如果
__BYTE_ORDER__
等於__ORDER_PDP_ENDIAN__
,則 16 位元字詞中的位元組會以小端序方式排列,而 32 位元數量的 16 位元子字詞則會以大端序方式排列。」