golang如何實現自舉？

golang實作自舉的方法：先安裝【Go 1.4】或更高版本；然後使用現有的Go工具鏈建立【Go 1.5】工具鏈的一個基本版本；最後進一步用它建構【 go_bootstrap】和其餘的標準函式庫和標準元件。

golang實作自舉的方法：

自舉（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之後的專案中進行。

相關學習推薦：Go語言教學

以上是golang如何實現自舉？的詳細內容。更多資訊請關注PHP中文網其他相關文章！