Google公布實現Go 1.5自舉的計劃

Google最近 公布 了實現Go 1.5自舉（Bootstrap）的計劃。相關文檔的作者是Go核心開發者Russ Cox，他在Go語言上已經耕耘了接近6年。據Russ介紹，Google就“如何從Go源碼樹中去除所有的C程序”已經醞釀了一年。

自舉（Bootstrapping） 是這樣的過程，“用要編譯的目標編程語言編寫其編譯器（或匯編器）”。一般而言，自舉有幾個優勢，比如：

• 用于測試被自舉的語言；
• 支持使用通常更為高級、提供更多高級抽象的語言來編寫編譯器；
• 編譯器也可以得益于語言層面的任何改進。

如前所述，Google在 一年前 就開始了從Go源碼樹中去除C代碼的努力，轉換計劃分為5個步驟：

• 第1階段—— 開發一個從 C 語言到 Go 語言的翻譯器 ，將現有的C編譯器翻譯成Go語言的。這一階段利用了一個事實：原來的編譯器沒有大量使用一些很難移植到Go語言的特性，比如宏、聯合和指針運算等。
• 第2階段—— 轉換編譯器的源碼樹 ，得到一個Go語言的編譯器，但是比較原始，而且是C風格的。
• 第3階段—— 將前面得到的編譯器轉換為符合 Go 語言習慣的程序 ，主要通過識別包，添加文檔和單元測試實現。
• 第4階段—— 優化編譯器 ，解決編譯器和CPU的內存使用問題，可能引入并行化。此外，嘗試在今天使用的不依賴架構的無序樹（Node*s）和依賴架構的有序列表（Prog*s）之間引入一個新的中間表示，目的是改進編譯器在消除冗余的nil檢查和邊界檢查等情況下的優化能力。
• 第5階段——用最新版的 go/parser 和 go/types 替換前端 。

Russ提到，他們還考慮了一些替代方案，不過基于各種因素都排除了，在一年前的 這份文檔 中都有描述。

Go 的自舉

編譯器的自舉通常會引發“先有雞還是先有蛋”的問題，必須提供一種方式來編譯我們要創建的語言。

Go的情況是，要構建Go 1.5，必須先安裝Go 1.4或更高版本，然后使用現有的Go工具鏈創建Go 1.5工具鏈的一個基本版本。一旦有了（Go 1.4）編譯的Go 1.5工具鏈，就可以再用它來構建自身了，可以進一步用它構建go_bootstrap和其余的標準庫和標準組件。這個過程加入了一個中間步驟——生成的 工具鏈再被用于構建其自身，它可以應用于未來的任何Go版本。

為進一步了解Go實現自舉的計劃，InfoQ采訪了Russ。

實現自舉看上去是 Go 語言的一個很大的里程碑。在語言的演進過程中，為什么決定在這個階段做這個事情呢，可以詳細介紹一下嗎？

Go是一門不錯的通用語言，但在設計時考慮的適用場合是編寫大規模、高并發的服務端軟件，就像運行在Google的服務器上的那些。如果更早實現自舉，Go編譯器就是第一個大型的Go語言程序，這對語言設計存在不利影響，會讓我們遠離真正的目標。

沒有更早實現自舉，還有一些技術原因，比如可移植性，從源代碼編譯比自舉更容易，而且我們也能盡早有一個穩定的編譯器實現。

使用 Go 來構建 Go ，與使用 C 相比，你認為對哪些具體領域有較為明顯的改進？

Ken Thompson 曾經對我說，用Go編寫程序感覺比用C更簡單。一個原因是，Go消除了好幾類常見的C bug，比如懸掛指針、內存泄漏、緩沖區溢出、深度遞歸時的棧溢出、誤用void*和意外的數值轉換等。

與任何標準的C工具鏈相比，標準的Go工具鏈對模塊化、單元測試和性能分析支持更好，不過讓我最興奮的是在修改內部API或重構時，應用自動化程序重寫（如 gofix ）的前景。

在“ Go 1.3+ Compiler Overhaul ”這篇文檔中，你描述了分 5 個步驟將現有的編譯器從 C 遷移到 Go 的過程。請問到目前為止，已經完成了哪些步驟了？其余步驟打算何時完成？

對Go項目而言，將語言的運行時從C轉換到Go更為重要，所以我們先做了這個。現在我們正回到編譯器。

從文檔角度看，我們目前處于第2階段。翻譯器已經完成，而且幫助我們轉換了運行時。我們正在將其應用于編譯器。我們希望完成Go 1.5編譯器的轉換。清理工作會在Go 1.5之后的項目中進行。

查看英文原文： Google Aims at Bootstrapping Go 1.5