持續開發的問題已經消除，為了讓Go實現的編譯器比C更有吸引力，另一些工程問題出現：

• 寫正確的Go代碼比寫正確的C代碼更容易。
• 調試錯誤的Go代碼比調試錯誤的C代碼更容易。
• 使用Go編譯器需要對Go有一定理解。而用C編譯器還需要一定理解C。
• Go使并發執行比C更方便。
• Go有更好的標準支持模塊化，自動重寫，單元測試和性能分析。
• Go比C更有趣(fun)。

基于以上理由，我們相信是時候用Go寫Go編譯器啦。

計劃設想

我們打算用自動化翻譯工具來用Go重寫現在C的編譯器。這個翻譯需要一些階段，將從Go 1.3開始持續到未來的發行版。

第一階段。開發和調試一個自動化翻譯工具。這可以在日常開發時同步進行。而且，人們還可以在這個階段為C編譯器繼續改進。這個工 具工作量很大，不過我們有信心完成這個特殊使命的工具。有許多C的觀念沒法兒直接轉換成Go；macros(宏)，unions(聯合，共用 體,)，bit fields(位域)可能最先考慮。比較幸運（不是巧合），這些功能功能用的少，都會被翻譯掉。指針運算和數組也需要一些轉換工作，盡管編譯器里很少。編 譯器里主要是tree(樹)和linked list(鏈表)。翻譯工具會保留注釋和C代碼的結構，所以翻譯后的代碼和當前的編譯器代碼一樣可閱讀。

第二階段。用翻譯工具轉換C代碼到Go，并刪除C源碼。這時我們已經開始翻譯，但是Go還是運行在C編譯器上。非常樂觀的，這可能發生在Go 1.3。不過更可能是Go 1.4。

第三階段。使用一些工具，可能來自gofix和the Go oracle，拆分編譯器到包，清理和文檔化代碼，添加適當的單元測試。這是編譯器會是地道的Go程序。目前打算在Go 1.4實現。

第四a階段。使用標準的分析和測試工具優化編譯器的CPU和內存使用。可能要引入并行。如果真這樣，Race Detector(Go的并行競爭檢測工具,)會有很大幫助。這目標在Go 1.4，可能部分會延后到1.5。基本的優化分析會在第三階段完成。

第四b階段。（和四a幾段同時進行）當編譯器依照明顯的界限分割成包之后， 需要明確引入一個中介碼，在結構無關的無序樹(Node*s)和結構相關的有序鏈表(Prog*s)之間。這個中介碼應該不依賴整體架構，但是包含準確的 執行順序信息，可以用于有順序但是結構無關的操作的優化，比如清理多余的nil檢測和出界檢測。這些過程基于SSA（靜態單賦值），你可以從Alan Donovan的 go.tools/ssa 包中了解更多。

第五階段。替換go/parser和go/types到最新（全新）的版本。Robert Griesemer參考現在的經驗，討論了設計新的parser和types的可能。如果聯系他們到編譯器后端，相信對設計新的API有很大幫助。

自展（Bootstrapping）

用Go語言實現的Go的編譯器，從一開始就要考慮如何自展。我們考慮的規則就是Go1.3編譯器必須由Go1.2編譯，Go1.4的編譯器必須由Go1.4編譯，以此類推。

這時，我們就有了一個清晰的流程來生成當前的程序：編譯Go1.2的工具鏈（由C編寫），然后使用它編譯Go1.3的工具鏈，以此類推。這里需要一 個腳本來做這個事情，來保證只會消耗CPU的時間而非某個人的時間。這樣的自展，每個機器只會做一次，Go1.x的工具鏈將會在本地保留，并在執行 all.bash來編譯Go1.(x+1)工具鏈的時候被再次使用。

顯然，隨著時間的推移這種自舉方式是不充分的。在后面的多個版本被發布之前，為編譯器寫一個后端來生成C代碼也許是一個更有意義的事情。這些C代碼 不要求效率或可讀性，只要正確即可。這些C代碼將會被簽入，就像我們簽入由yacc生成的y.tab.c文件一樣。這樣，自展過程就會變成：先用gcc編 譯C代碼生成一個自展編譯器，然后使用這個自展編譯器來編譯真正的編譯器。類似于另一個自展過程，這個自展編譯器將會在本地保留，并在每次執行 all.bash的時候重復使用（不用重新編譯）。

替代選擇

還有一些比較明顯的替代方案，需要我們說明一下為什么放棄了這些選擇。

從一開始寫一個編譯器。現在的編譯器有一個非常重要的特征：他們能夠正常工作（或者其至少能夠滿足所有用戶的要求）。盡管Go語言比較簡單，但是編譯器中有很多細微的細節優化和改寫，直接丟棄10或數年的在這上面的努力是比較愚蠢的。

對編譯器進行人工翻譯。我們已經以人工的方式翻譯了一小部分C/C++代碼到Go語言了。這個過程是枯燥而且易錯的，且這些錯誤非常的細微及難以發 現。相反，使用機械翻譯會形成一些比較一致的錯誤，而這些錯誤是易于發現的；而且不會因為枯燥的過程開小差。Go編譯器的代碼明顯的比我們翻譯的代碼多很 多：超過60,000行C代碼，機械翻譯會使這個過程容易一些。就像Dick Sites在1974年說的一樣：“相比寫程序，我寧愿寫一個程序來幫我寫 程序。“ 使用機械來翻譯編譯器也方便于在準備好切換之前，我們可以繼續開發完善現有的C程序。

只翻譯后端并鏈接到go/parser和go/types.從前端傳給后端的數據結構所包含的 信息中，go/parser和go/types所能提供的除了API就沒其他的東西了。如果使用這些庫來替代前端，需要寫代碼來轉換go/parser和 go/types所能提供數據結構到后端，這是一個非常寬泛且易出錯的工作。我們相信使用這些庫是有意義的，但更明智的是，等到將編譯器代碼調整的更像 Go程序，分成確定邊界的、包含說明文檔和單元測試子包之后再使用。

放棄現有的編譯器，使用gccgo（或者go/parser + go/types + LLVM,  …）。現有的編譯器是Go語言顯得比較靈活的一個重要組成部分。如果嘗試使用基于大量代碼的GCC或LLVM來開發Go程序，感覺會有礙到Go語言的靈 活性。另外，GCC是大量C代碼（現在有部分C++）、LLVM是大量C++代碼的程序。以上列舉的、用于解釋不使用現有編譯框架代碼的幾個原因，也都適 用于更多的類似的代碼庫。

C語言的長期使用

臨近結束，這個計劃還留下了由C寫成的Plan9的工具鏈的一部分。在長期發展中，還是將所有的C從代碼樹排除掉比較好。本章節推測了一下這件事將會如何發生，但不保證其指定會發生或者按照這種套路發生。

運行時包(runtime)。 runtime包的大部分都是用C寫成，基于一些同樣的原因，Go編譯器也是用C實現。但是，runtime包遠比 編譯器的代碼量要小，且它現在已經是用Go和C混合編寫。將C代碼轉換為Go代碼時，一次轉化一部分貌似也是可行的。其中，主要部分有：調度器 （scheduler），垃圾回收（the garbage collector），散列映射表（hash map）的實現，和channel的實現。（這里Go和C代碼混合的很融洽，是因為這里使用的6c而不是gcc來編譯的C代碼。）

C編譯器。 Plan 9的C編譯器本身就是用C寫成，如果我們要從Go包實現里面移除所有的C代碼，那么我們將移除這些編譯工具：“go tool 6c”等等，另外，.c的文件也將不被支持出現的Go包的目錄里面。我們應該提前聲明這樣的計劃，以便使用C的第三方包有時間去移除這類C代碼的使用。 （Cgo，由于使用了gcc來替代6c，所以它仍然可以作為一個途徑來在Go包中使用C實現部分功能。）在Go1的兼容性文檔中沒有包含工具鏈修改的描 述，也就是說去掉C編譯器是被允許的。