從 -go 文本文件到可執行文件

Go 是一門編譯型語言，我們平時所編寫的 *.go 文本文件稱爲源文件，源文件裏面的內容就是我們的源代碼。

源代碼要想在目標機器上運行，就必須使用 Go compiler （縮寫 gc ，指代 Go 編譯器）將其先編譯成操作系統能夠直接識別的二進制機器碼文件，或說可執行文件。後續由操作系統加載該文件，並在 CPU 中直接運行機器碼。這也是編譯型語言運行效率高的主要原因。

Go compiler 是用什麼實現的

編譯器本身也是一個程序，它的作用就是把一個以某種語言（源語言）編寫的程序 翻譯 成等價的另一個語言（目標語言）編寫的程序。

而編譯器這個程序本身的編寫與編程語言是沒有關係的，任何一種圖靈完備的語言都可以編寫任何一種形式語言的編譯器。

最開始的 Go compiler （Go 1.4 以及之前）是由 C 和彙編共同編寫的，等到 2015 年時 Google 開始公佈實現 Go 1.5 自舉的計劃 [1]。

首先使用 Go 語言編寫一個和之前用 C 語言編寫的 Go compiler 一樣功能的程序出來，再用之前用 C 語言實現好的 Go compiler 來編譯這個新寫的程序，這樣就得到一個用 Go 語言實現的 Go compiler 。後續的 Go 程序就都可以直接使用這個新的用 Go 語言實現的 Go compiler 來編譯了。

這種用源語言自身來實現源語言的編譯器的做法就叫自舉。所以在 Go 1.5 及之後的 Go compiler 就是用 Go 語言自身實現的了。

一個編譯器的結構

如果我們把編譯器這個黑盒稍微打開，根據完成的任務不同，可以將編譯器的組成部分劃分爲前端（Front End）與後端（Back End）。

編譯前端負責分析（analysis）部分，把源程序分解爲多個組成要素，並在這些要素之上加上語法結構，然後利用這個結構創建出源程序的中間表示形式，最後還將源程序的信息存放在一個稱爲符號表的數據結構中並與中間表示形式一起傳送給綜合部分。

可見，如果我們編寫了一段語法錯誤的代碼，在前端就會被攔截下並給予提示了。這和我們 Web 開發中的參數校驗部分也有一點相似之處。

前端工作結束，則來到編譯後端，後端則負責綜合（synthesis）部分，根據前端傳送過來的中間表示和符號表中的信息來構造用戶期待的目標程序。

在編譯前端和後端之間，往往還存在着多個可選的、與機器無關的優化步驟，負責將中間表示形式進一步優化轉換，以便後續後端可以生成出更好的目標程序。

編譯器的結構

Go compiler 的多階段流程

以當前最新的穩定版本 Go 1.18.4 爲例，Go compiler 的源碼位置在：https://github.com/golang/go/tree/go1.18.4/src/cmd/compile

後續的所有代碼示例和源碼引用也是基於此版本。

我們將編譯器的結構對應到 Go compiler 上，也可以將 Go compiler 的各階段流程劃分爲編譯前端和編譯後端（優化器部分也放在了編譯後端）。

其中 Go compiler 的前端包括：詞法分析、語法分析、類型檢查。

後端包括：中間代碼生成、代碼優化、Walk 遍歷和替換、通用 SSA 生成、機器碼生成。

Go compiler 的多階段流程

詞法分析

編譯器的第一個步驟稱爲詞法分析（lexical analysis）或掃描（scanning）。對應的源碼位置在 cmd/compile/internal/syntax/scanner.go 。其作用便是把我們的源代碼 “翻譯” 爲詞法單元 token 。

token 在 go/token/token.go 中被定義爲了一種枚舉值，實質就是用 iota 聲明的整數，好處便是在後續的操作中可以被更加高效地處理。

所有的 token 主要被分爲四類：特殊類型、基礎類型、運算符和關鍵字。

若存在詞法錯誤，將統一返回 ILLEGAL ，簡化詞法分析時的錯誤處理。

其中以 _beg 和 _end 爲後綴的私有常量，用來表示 token 的值域範圍。

最後所有的 token 都會被放進一個 var tokens = [...]string 數組中，做了一個下標（token 值）和 token 面值的映射。

值得一提的是，詞法分析除了在編譯器中使用，在 go 標準庫 go/scanner 中也提供了出來，我們可以用來測試看看一段源代碼翻譯成 token 後的樣子。

package main

import (
 "fmt"
 "go/scanner"
 "go/token"
)

func main() {

 // 需要翻譯的源程序
 src := []byte(`package main

import "fmt"

func main() {
 fmt.Println(1 + 1)
}
`)

 // 初始化 scanner.
 var s scanner.Scanner
 fset := token.NewFileSet()
 file := fset.AddFile("", fset.Base(), len(src))
 s.Init(file, src, nil, scanner.ScanComments)

 // 不斷地掃描並輸出翻譯成 token 的結果
 fmt.Printf("%s\t%s\t%s\n", "行列", "token符號", "對應的原詞")
 for {
  pos, tok, lit := s.Scan()
  if tok == token.EOF {
   break
  }
  fmt.Printf("%s\t%s\t%q\n", fset.Position(pos), tok, lit)
 }
}

翻譯成 token 後的輸出結果如下：

有個小細節的地方：當遇到 \n 換行符時，會翻譯成一個 ; 分號，這也是 Go 語言爲什麼不需要 ; 結尾。

語法分析

編譯器的第二個步驟稱爲語法分析（syntax analysis）或解析（parsing）。語法分析將把第一步驟的 token 轉化成使用 AST 抽象語法樹（abstract syntax tree）來表示的程序語法結構。

語法分析的源碼位於 cmd/compile/internal/syntax/parser.go 。我們同樣可以藉助標準庫 go/parser 來進行測試。

package main

import (
 "go/ast"
 "go/parser"
 "go/token"
)

func main() {
 // 需要翻譯的源程序
 src := `package main

import "fmt"

func main() {
 fmt.Println(1 + 1)
}
`

 fset := token.NewFileSet()
 f, err := parser.ParseFile(fset, "", src, 0)
 if err != nil {
  panic(err)
 }

 err = ast.Print(fset, f)
 if err != nil {
  panic(err)
 }
}

經過語法分析構建出來的每個語法樹都是相應源文件的精確表示，其節點對應於源文件的各種元素，例如表達式、聲明和語句。並且語法樹還會包括位置信息，用於錯誤報告和創建調試信息。

到目前階段爲止，都還只是對源代碼進行字符串層面的處理。從源代碼到 token 再到 AST 。

類型檢查

在編譯原理中，完成 AST 的構建，就會來到語義分析（semantic analyzer）階段，主要包括類型檢查（type checking）和自動類型轉換（coercion）。

而在 Go compiler 中，這一階段被直接合稱爲類型檢查，其源碼定義在 cmd/compile/internal/types2 。

在此階段，類型檢查會遍歷 AST 的節點，對每個節點的類型進行檢查，比如檢查每個運算符是否具有匹配的運算分量，數組的下標是否正整數等等。另外類型檢查階段也會進行類型推導，例如使用簡短變量聲明 i := 1 ，會自動推導出變量 i 的類型是 int。

總之，對類型系統的處理都是類型檢查階段完成的。

類型檢查的總體流程可以查看 cmd/compile/internal/types2/check.go ：

中間代碼生成

一旦類型檢查階段完成，意味着編譯前端工作完成，到這裏代碼已經沒有語法錯誤的問題了。按理是可以直接翻譯成機器碼了，但是在此之前，還需要先翻譯成介於源代碼和目標機器碼中間的中間代碼（IR, Intermediate Representation）。

使用中間代碼來銜接前、後端的好處很大。因爲中間代碼不會包含與任何源代碼相關的信息，也不會包含與特定目標機器相關的信息，我們可以基於中間代碼來進行一些和機器無關的優化工作。

另外，有了中間代碼，後端編譯還可以得到複用，比如我現在想要創建一門新的語言，只需要編寫編譯器前端，構造出相同的中間代碼，編譯器後端就可以直接使用現成的了，不必重複構建。

其實這種做法就是平時我們程序設計常提到的解耦。

回到中間代碼生成本身，在這一階段中，會基於前面構造出的 AST 再生成一顆 IR Tree 。

因爲我們是基於 Go 1.18.4 來分析，Go Team 在此已經增加了許多新的語言特性（包括泛型），以往的很多模塊也被重新重構，代碼結構更加清晰。但是難免還會關聯到之前一些舊版本的包（在之前 IR Tree 的生成與類型檢查是同時完成的）。

在 IR 生成階段，主要會涉及以下幾個目錄：

• cmd/compile/internal/types

• cmd/compile/internal/ir

• cmd/compile/internal/typecheck

• cmd/compile/internal/noder

IR 生成的入口位置在 cmd/compile/internal/noder/irgen.go ：

func (g *irgen) generate(noders []*noder) 中的參數 noders 就是類型檢查的輸出結果 AST 。

到這裏我們小結一下，編譯前端完成了 源代碼 -> token -> AST 的翻譯工作，而現在的中間代碼生成階段完成了 AST -> 基於 AST 的 IR Tree 的翻譯工作。所以爲什麼說編譯器的工作就是在翻譯。

代碼優化

終於來到了代碼優化，這個階段可謂是八股文的重災區。即使不懂編譯流程，也聽過了這些名詞：死代碼消除（dead code elimination）、函數內聯（function call inlining）、逃逸分析（escape analysis）。

以上這些便是對 IR 的進一步優化過程。其源碼位置分別在：

• cmd/compile/internal/deadcode

• cmd/compile/internal/inline

• cmd/compile/internal/escape

代碼優化的目的就是讓代碼的執行效率更高，例如可能存在一些代碼，雖然具備語義上的價值，但程序在運行時可能永遠不會執行到，死代碼消除就會去除這些無用代碼（就像 if 裏的條件爲 true ）。

如果程序中存在大量的小函數的調用，函數內聯就會直接用函數體替換掉函數調用來減少因爲函數調用而造成的額外上下文切換開銷。

最後逃逸分析可以判斷變量應該使用棧內存還是堆內存，爲 Go 的自動內存管理奠定基礎。

Walk 遍歷和替換

經歷過代碼優化的 IR ，將迎來它生命旅遊的最後一站：Walk ，源碼在 cmd/compile/internal/walk。

Walk 會遍歷函數把複雜的語句分解爲單獨的、更簡單的語句，並且還可能會引入臨時變量來對某些表達式和語句進行重新排序。還會將高層次的 Go 結構替換爲更原始的結構。

例如， n += 2 將被替換爲 n = n + 2 ；switch 選擇分支將替換爲二分查找或跳轉表；map 和 chan 的 make 操作將替換爲運行時調用的 makemap 和 makechan 等。

通用 SSA 生成

Walk 是基於 AST 的 IR 的最後一程，意味着來到這裏，又要再次翻譯了。

而這次 IR 將被轉換爲靜態單賦值（SSA）（Static Single Assignment）形式，這是一種具有特定屬性的較低級別的中間表示，可以更輕鬆地實現優化並最終生成機器代碼。

SSA 的規則定義在：cmd/compile/internal/ssa ，而 IR 轉換爲 SSA 的代碼位於：cmd/compile/internal/ssagen 。

其翻譯的入口在 func Compile(fn *ir.Func, worker int) 函數。

我們可以通過在編譯過程加上 GOSSAFUNC=函數名 環境變量來查看 SSA 的生成過程。

還是以這段代碼爲例：

package main

import "fmt"

func main() {
 fmt.Println(1 + 1)
}

$ GOSSAFUNC=main go build hello.go
# runtime
dumped SSA to D:\Project\GoProject\awesome\ssa.html
# command-line-arguments
dumped SSA to .\ssa.html

根據提示，會生成 ssa.html 文件：

可以從中看到 SSA 爲了盡最大可能地提升執行效率，會經歷 多輪轉換 後才生成最終的 SSA 。

機器碼生成

來到最後一步，也是從 .go 文本文件到可執行文件的最終謎團，把 SSA 翻譯成特定目標機器（目標 CPU 架構）的機器碼。

首先需要把 SSA 降級（lower），針對具體目標架構，進行 多輪轉換 來執行代碼優化，包括死代碼消除（和之前的代碼優化中的不同）、將數值移到離它們的用途更近的地方、刪除多餘局部變量、寄存器分配等等。

這個降級操作最後的結果，其實就是我們上面的 ssa.html 文件最後的 genssa ：

把 SSA 多輪轉換得到了 genssa 之後（此時已經很接近彙編了），會先繼續把 genssa 翻譯成彙編代碼（Plan9），然後才調用匯編器（cmd/internal/obj）將它們轉換爲機器代碼並寫出最終的目標文件。目標文件中還會包含着反射數據、導出數據和調試信息。這一步就需要十分了解 CPU 指令集架構了。

最後程序如果使用了其他程序或庫，還需要使用靜態鏈接或動態鏈接引用進來。在沒有使用 CGO 時，Go 默認會使用靜態鏈接，當然也可以在 go build 時指定。

最後

編譯原理是一門十分複雜的系統，每一個階段單獨拎出來，其涉及的知識體系都夠嚇人的了。。。

本文也只是蜻蜓點水般的過一遍，關於其中的一些細節我也並不太清楚，但是也讓我明白了一點道理：不管是多複雜多底層的系統，也都是通過分層來解耦、複用，並且也是不斷迭代優化來完成的。

另外，知道了 Go 語言編譯過程中的代碼優化，也能讓我們在平時的代碼編寫中結合對應的特性編寫出更加高性能的代碼，例如儘量在棧上分配對象，減少變量逃逸到堆上也可以提高 GC 效率等。這些後面再單獨寫篇文章來介紹。

本文部分內容參考自經典龍書《編譯原理》以及《Golang 編譯器代碼淺析》[2] ，如果想要了解更多編譯領域的知識，推薦大家進行閱讀。

對於最後機器碼生成中提到的 Plan9 彙編可以閱讀曹大的《plan9 assembly 完全解析》[3]。

參考資料

[1]

Google 公佈實現 Go 1.5 自舉的計劃: https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit

[2]

《Golang 編譯器代碼淺析》: https://gocompiler.shizhz.me/

[3]

《plan9 assembly 完全解析》: https://go.xargin.com/docs/assembly/assembly/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/V5wAZcTbunU3HdS1xaWavQ