概述
目前Go編譯器是C寫的，是時候換成Go啦。
背景
“gc"Go工具鏈來自Plan 9編譯器的工具鏈。組裝器、C編譯器和鏈接器基本沒變。Go的編譯器(cmd/gc,cmd/5g,cmd/6g,cmd/8g)是配合工具鏈寫的新的C程序。
項目起始時，用C而不是Go寫編譯器有很多好處。突出的比如，首先，那時候Go還不存在，沒法兒寫編譯器。而且實際上，就算存在，也會經常有明顯的不兼容的變化。用C不用Go可以避免初始和持續開發導致的問題。然而如今Go 1已經穩定，所以這些持續的問題減少了很多。
持續開發的問題已經消除，為了讓Go實現的編譯器比C更有吸引力，另一些工程問題出現：
基于以上理由，我們相信是時候用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?；镜膬灮治鰰诘谌A段完成。
第四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的時候重復使用（不用重新編譯）。
替代選擇還有一些比較明顯的替代方案，需要我們說明一下為什么放棄了這些選擇。
從一開始寫一個編譯器?，F在的編譯器有一個非常重要的特征：他們能夠正常工作（或者其至少能夠滿足所有用戶的要求）。盡管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, …）?，F有的編譯器是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編譯器是被允許的。
匯編器。 Plan 9的匯編器也是用C實現的，但這個匯編器只不過是一系列解析樹組成的簡單解析器，這使得不論手動還是自動將它翻譯成Go語言都比較簡單。
連接器。 Plan 9的連接器也是由C寫成。最近的一些工作，已經將大部分的連接器工作放到的編譯器中，而且，也已經有個計劃將剩余的部分重寫成一個新的、更簡單的Go程序。轉移到編譯器的部分連接器代碼，現在需要隨著編譯器的原有代碼一起進行翻譯。
基于Libmach的工具: nm, pack, addr2line, 和objdump。 Nm現在已經使用Go語言重寫。Pack和addr2line可以任何一天被重寫。Objdump現在依賴于libmach的反匯編器，但這些轉換為Go也是比較簡單的，不論是使用機械還是人工翻譯。所以基于這幾點，libmach本身將來也可以被移除。
來源: http://www.oschina.net/translate/go-1-3-compiler-overhaul
英文來源:https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1