Go 1.3+ 編譯器變革

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

概述 目前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已經穩定，所以這些持續的問題減少了很多。

傅小黑 翻譯於 10 個月 前 0人頂 頂 翻譯的不錯哦!

持續開發的問題已經消除，為了讓Go實現的編譯器比C更有吸引力，另一些工程問題出現： 寫正確的Go代碼比寫正確的C代碼更容易。 調試錯誤的Go代碼比調試錯誤的C代碼更容易。 使用Go編譯器需要對Go有一定理解。而用C編譯器還需要一定理解C。 Go使並發執行比C更方便。 Go有更好的標準支援模組化，自動重寫，單元測試和效能分析。 Go比C更有趣(fun)。 基於以上理由，我們相信是時候用Go寫Go編譯器啦。

傅小黑 翻譯於 10 個月 前 0人頂 頂 翻譯的不錯哦!

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

傅小黑 翻譯於 10 個月 前 0人頂 頂 翻譯的不錯哦!

第二階段。用翻譯工具轉換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。基本的最佳化分析會在第三階段完成。

傅小黑 翻譯於 10 個月 前 1人頂 頂 翻譯的不錯哦!

第四b階段。（和四a幾段同時進行）當編譯器依照明顯的界限分割成包之後，需要明確引入一個中介碼，在結構無關的無序樹(Node*s)和結構相關的有序鏈表(Prog*s)之間。這個中介碼應該不依賴整體架構，但是包含準確的執行順序資訊，可以用於有順序但是結構無關的操作的最佳化，比如清理多餘的nil檢測和出界檢測。這些過程基於SSA（靜態單賦值），你可以從Alan Donovan的 go.tools/ssa 包中瞭解更多。 第五階段。替換go/parser和go/types到最新（全新）的版本。Robert Griesemer參考現在的經驗，討論了設計新的parser和types的可能。如果聯絡他們到編譯器後端，相信對設計新的API有很大協助。

傅小黑 翻譯於 10 個月 前 1人頂 頂 翻譯的不錯哦!

自展（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的時候重複使用（不用重新編譯）。

偃鼠飲河 翻譯於 9 個月 前 0人頂 頂 翻譯的不錯哦!

替代選擇 還有一些比較明顯的替代方案，需要我們說明一下為什麼放棄了這些選擇。 從一開始寫一個編譯器。現在的編譯器有一個非常重要的特徵：他們能夠正常工作（或者其至少能夠滿足所有使用者的要求）。儘管Go語言比較簡單，但是編譯器中有很多細微的細節最佳化和改寫，直接丟棄10或數年的在這上面的努力是比較愚蠢的。 對編譯器進行人工翻譯。我們已經以人工的方式翻譯了一小部分C/C++代碼到Go語言了。這個過程是枯燥而且易錯的，且這些錯誤非常的細微及難以發現。相反，使用機械翻譯會形成一些比較一致的錯誤，而這些錯誤是易於發現的；而且不會因為枯燥的過程開小差。Go編譯器的代碼明顯的比我們翻譯的代碼多很多：超過60,000行C代碼，機械翻譯會使這個過程容易一些。就像Dick Sites在1974年說的一樣：“相比寫程式，我寧願寫一個程式來幫我寫程式。“ 使用機械來翻譯編譯器也方便於在準備好切換之前，我們可以繼續開發完善現有的C程式。

偃鼠飲河 翻譯於 9 個月 前 0人頂 頂 翻譯的不錯哦!

只翻譯後端並連結到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++代碼的程式。以上列舉的、用於解釋不使用現有編譯架構代碼的幾個原因，也都適用於更多的類似的程式碼程式庫。

偃鼠飲河 翻譯於 9 個月 前 0人頂 頂 翻譯的不錯哦!

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編譯器是被允許的。

偃鼠飲河 翻譯於 9 個月 前 0人頂 頂 翻譯的不錯哦!

彙編器。 Plan 9的彙編器也是用C實現的，但這個彙編器只不過是一系列解析樹組成的簡單解析器，這使得不論手動還是自動將它翻譯成Go語言都比較簡單。 連接器。 Plan 9的連接器也是由C寫成。最近的一些工作，已經將大部分的連接器工作放到的編譯器中，而且，也已經有個計劃將剩餘的部分重寫成一個新的、更簡單的Go程式。轉移到編譯器的部分連接器代碼，現在需要隨著編譯器的原有代碼一起進行翻譯。 基於Libmach的工具: nm, pack, addr2line, 和objdump。 Nm現在已經使用Go語言重寫。Pack和addr2line可以任何一天被重寫。Objdump現在依賴於libmach的反組譯碼器，但這些轉換為Go也是比較簡單的，不論是使用機械還是人工翻譯。所以基於這幾點，libmach本身將來也可以被移除。

偃鼠飲河 翻譯於 9 個月 前 0人頂 頂 翻譯的不錯哦!

本文中的所有譯文僅用於學習和交流目的，轉載請務必註明文章譯者、出處、和本文連結
我們的翻譯工作遵照 CC 協議，如果我們的工作有侵犯到您的權益，請及時聯絡我們