Go Wiki：AssemblyPolicy

此文件說明何時以及如何將組合語言程式碼加入 Go 加密套件。

原則如下

• 我們偏好可攜式的 Go，而非組合語言。組合語言中的程式碼代表著 (N 套件 * M 架構) 的維護，而非僅 N 套件。
• 將組合語言的使用情況降至最低。我們寧願以少量組合語言提升 50% 速度，而非以兩倍的組合語言提升 55% 速度。在 commit 訊息中說明將組合語言/Go 的界線放在該處的決定，並提供對應的基準測試予以支持。
• 使用較高層級的程式產生大量的組合語言，無論是獨立的 Go 程式或 go get 可取得的程式，例如 avo。其他可複製程式的輸出 (例如正式核准的程式碼產生器) 也會一併考慮。事先在問題追蹤器中討論實作策略。
• 使用小型、可測試的單元（25-75 行），由以 Go 編寫的高階邏輯呼叫。如果使用由以 Go 編寫的邏輯呼叫的小型、可測試函式太慢，請使用搭配 Go 相容包裝封裝的小型、可測試組譯單元，以便 Go 測試仍能夠測試個別單元。
• 任何組譯函式都需要一個參考 Go 實作，與組譯並行測試。按照 TargetSpecific 的結構和測試實務操作。
• 組譯單元和參考 Go 實作的介面在所有架構間都必須相同，除非各平台具有基本不同的功能（例如高階加密指令）。
• 除非 Go 安全性團隊明確承諾擁有特定實作，否則外部貢獻者必須承諾維護該實作。如果需要變更（例如作為廣泛重構的一部分），而維護者無法協助處理，則組譯會予以移除。
• 必須在我們的 CI 中測試程式碼。這表示需要支援指令的建置工具，如果有多條（或備用）路徑，則必須將其分別測試。（提示：使用 GODEBUG=cpu.X=off 停用 CPU 功能偵測。）
• 在 Go 程式碼中記載實作需要組譯的原因（特定的效能優點、指令存取權等），以便我們隨著編譯器進步重新評估。

目前標準函式庫中的所有組譯並不一定都遵守這項政策。在該實作更新為相符之前，將不鼓勵變更現有的組譯。新的組譯必須符合規定。

此內容為 Go Wiki 的一部分。