大前端开发者需要了解的基础编译原理和语言知识
轉自：https://yq.aliyun.com/articles/180879
?
在我剛剛進入大學，從零開始學習 C 語言的時候，我就不斷的從學長的口中聽到一個又一個語言，比如 C++、Java、Python、JavaScript 這些大眾的，也有 Lisp、Perl、Ruby 這些相對小眾的。一般來說，當程序員討論一門語言的時候，默認的上下文經常是:“用 xxx 語言來完成 xxx 任務”。所以一直困擾著的我的一個問題就是，為什么完成某個任務，一定要選擇特定的語言，比如安卓開發是 Java，前端要用 JavaScript，iOS 開發使用 Objective-C 或者 Swift。這些問題的答案非常復雜，有的是技術原因，有的是歷史原因，有的會考慮成本，很難得出統一的結論，只能 case-by-case 的分析。這篇文章并非專門解答上述問題，而是希望通過介紹一些通用的概念，幫助讀者掌握分析問題的能力，如果這個概念在實際編程中用得到，我也會舉一些具體的例子。
在閱讀本文前，不妨思考一下這幾個問題，如果沒有頭緒，建議看完文章以后再思考一遍。如果覺得答案顯而易見，恭喜你，這篇文章并非為你準備的:
編譯原理
就像數學是一個公理體系，從簡單的公理就能推導出各種高階公式一樣，我們從最基本的 C 語言和編譯說起。
相關的介紹編譯過程的文章很多，讀者應該都非常熟悉了，整個流程包括預處理、詞法分析、語法分析、生成中間代碼，生成目標代碼，匯編，鏈接 等。已有的文章大多分析了每一步的邏輯，但很少談實現思路，我會盡量用簡單的語言來描述每一步的實現思路，相信這樣有助于加深記憶。由于主要談的概念和思路，難免會有一些不夠準確的抽象，讀者學會抓重點就行。
預處理是一個獨立的模塊，它放在最后介紹，我們先看詞法分析。
詞法分析
最先登場的是編譯器，它負責前五個步驟，也就是說編譯器的輸入是源代碼，輸出是中間代碼。
編譯器不能像人一樣，一眼就看明白源代碼的內容，它只能比較傻的逐個單詞分析。詞法分析要做的就是把源代碼分割開，形成若干個單詞。這個過程并不像想象的那么簡單。比如舉幾個例子:
詞法分析的主要難點在于，前綴無法決定一個完整字符串的含義，通常需要看完整句以后才知道每個單詞的具體含義。同時，C 語言的語法也不簡單，各種關鍵字，括號，逗號，語法等等都會給詞法分析的實現增加難度。
詞法分析的主要實現原理是狀態機，它逐個讀取字符，然后根據讀到的字符的特點轉換狀態。比如這是 GCC 的詞法分析狀態機(引用自《編譯系統透視》):??
如果自己實現的話，思路也不難。外面包一個循環，然后各種 switch...case 就完事了。詞法分析應該算是最簡單的一節。
語法分析
經過詞法分析以后，編譯器已經知道了每個單詞，但這些單詞組合起來表示的語法還不清楚。一個簡單的思路是模板匹配，比如有這樣的語句:
它其實表示了這么一種通用的語法格式:
類型 變量名 = 常量;
所以 int a = 10; 當然可以匹配上這種模式。同理，它不可能匹配 類型 函數名(參數); 這種函數定義模式，因為兩者結構不一致，等號無法被匹配。
語法分析比詞法分析更復雜，因為所有 C 語言支持的語法特性都必須被語法分析器正確的匹配，這個難度比純新手學習 C 語言語法難上很多倍。不過這個屬于業務復雜性，無論采用哪種解決方案都不可避免，因為語法規則的數量就是這么多。
在匹配模式的時候，另一個問題在于上述的名詞，比如 類型、參數，很難界定。比如int 是類型，long long 也是類型，unsigned long long 也是類型。(int a) 可以是參數，(int a, int b) 也是參數，(unsigned long long a, long long double b, int *p) 看起來能把人逼瘋。
下面舉一個簡單的例子來解釋 int a = 10 是如何被解析的，總的思路是歸納與分解。我們把一個復雜的式子分割成若干部分，然后分析各個部分，這樣可以簡化復雜度。對于 int a = 10 來說，他是一個聲明，聲明由兩部分組成，分別是聲明說明符和初始聲明符列表。
| int a = 10 | int | a = 10 |
| int fun(int a) | int | fun(int a) |
| int array[5] | int | array[5] |
聲明說明符比較簡單，它其實是若干個類型的串聯:
聲明說明符 = 類型 + 類型的數組(長度可以為 0)
而且我們知道若干個類型連在一起又變成了聲明說明符，所以上述等式等價于:
聲明說明符 = 類型 + 聲明說明符(可選)
再嚴謹一些，聲明說明符還可以包括 const 這樣的限定說明符，inline 這樣的函數說明符，和 _Alignas 這樣的對齊說明符。借用書中的公式，它的完整表達如下:
這才僅僅是聲明語句中最簡單的聲明說明符，僅僅是幾個類型和關鍵字的組合而已。后面的初始聲明符列表的解析更復雜。如果有能力做完這些解析，恭喜你，成功的解析了聲明語句。你會發現什么定義語句啦，調用語句啦，正嫵媚的向你招手╮(╯▽╰)╭。
成功解析語法以后，我們會得到抽象語法樹(AST: Abstract Syntax Tree)。以這段代碼為例:
它的語法樹如下:
語法樹將字符串格式的源代碼轉化為樹狀的數據結構，更容易被計算機理解和處理。但它距離中間代碼還有一定的距離。
生成中間代碼
以 GCC 為例，生成中間代碼可以分為三個步驟:
簡單的介紹一下每一步都做了什么。
語法樹轉高端 gimple
這一步主要是處理寄存器和棧，比如 c = a + b 并沒有直接的匯編代碼和它對應，一般來說需要把 a + b 的結果保存到寄存器中，然后再把寄存器賦值給 c。所以這一步如果用 C 語言來表示其實是:
另外，調用一個新的函數時會進入到函數自己的棧，建棧的操作也需要在 gimple 中聲明。
高端 gimple 轉低端 gimple
這一步主要是把變量定義，語句執行和返回語句區分存儲。比如:
會被處理成:
這樣做的好處是很容易計算一個函數到底需要多少棧空間。
此外，return 語句會被統一處理，放在函數的末尾，比如:
會被處理成:
低端 gimple 經過 cfa 轉 ssa 再轉中間代碼
這一步主要是進行各種優化，添加版本號等，我不太了解，對于普通開發者來說也沒有學習的必要。
中間代碼的意義
其實中間代碼可以被省略，抽象語法樹可以直接轉化為目標代碼(匯編代碼)。然而，不同的 CPU 的匯編語法并不一致，比如 AT&T與Intel匯編風格比較 這篇文章所提到的，Intel 架構和 AT&T 架構的匯編碼中，源操作數和目標操作數位置恰好相反。Intel 架構下操作數和立即數沒有前綴但 AT&T 有。因此一種比較高效的做法是先生成語言無關，CPU 也無關的中間代碼，然后再生成對應各個 CPU 的匯編代碼。
生成中間代碼是非常重要的一步，一方面它和語言無關，也和 CPU 與具體實現無關。可以理解為中間代碼是一種非常抽象，又非常普適的代碼。它客觀中立的描述了代碼要做的事情，如果用中文、英文來分別表示 C 和 Java 的話，中間碼某種意義上可以被理解為世界語。
另一方面，中間代碼是編譯器前端和后端的分界線。編譯器前端負責把源碼轉換成中間代碼，編譯器后端負責把中間代碼轉換成匯編代碼。
LLVM IR 是一種中間代碼，它長成這樣:
生成目標代碼
目標代碼也可以叫做匯編代碼。由于中間代碼已經非常接近于實際的匯編代碼，它幾乎可以直接被轉化。主要的工作量在于兼容各種 CPU 以及填寫模板。在最終生成的匯編代碼中，不僅有匯編命令，也有一些對文件的說明。比如:
匯編
匯編器會接收匯編代碼，將它轉換成二進制的機器碼，生成目標文件(后綴是 .o)，機器碼可以直接被 CPU 識別并執行。從目標代碼可以猜出來，最終的目標文件(機器碼)也是分段的，這主要有以下三個原因:
段分離我們并不遙遠，比如命令行中的 objcopy 可以自行添加自定義的段名，C 語言的 __attribute((section(段名)))__ 可以把變量定義在某個特定名稱的段中。
對于一個目標文件來說，文件的最開頭(也叫作 ELF 頭)記錄了目標文件的基本信息，程序入口地址，以及段表的位置，相當于是對文件的整體描述。接下來的重點是段表，它記錄了每個段的段名，長度，偏移量。比較常用的段有:
- .strtab 段: 字符串長度不定，分開存放浪費空間(因為需要內存對齊)，因此可以統一放到字符串表(也就是 .strtab 段)中進行管理。字符串之間用\0 分割，所以凡是引用字符串的地方用一個數字就可以代表。
- .symtab: 表示符號表。符號表統一管理所有符號，比如變量名，函數名。符號表可以理解為一個表格，每行都有符號名(數字)、符號類型和符號值(存儲地址)
- .rel 段: 它表示一系列重定位表。這個表主要在鏈接時用到，下面會詳細解釋。
鏈接
在一個目標文件中，不可能所有變量和函數都定義在文件內部。比如 strlen 函數就是一個被調用的外部函數，此時就需要把 main.o 這個目標文件和包含了 strlen函數實現的目標文件鏈接起來。我們知道函數調用對應到匯編其實是 jump 指令，后面寫上被調用函數的地址，但在生成 main.o 的過程中，strlen() 函數的地址并不知道，所以只能先用 0 來代替，直到最后鏈接時，才會修改成真實的地址。
鏈接器就是靠著重定位表來知道哪些地方需要被重定位的。每個可能存在重定位的段都會有對應的重定位表。在鏈接階段，鏈接器會根據重定位表中，需要重定位的內容，去別的目標文件中找到地址并進行重定位。
有時候我們還會聽到動態鏈接這個名詞，它表示重定位發生在運行時而非編譯后。動態鏈接可以節省內存，但也會帶來加載的性能問題，這里不詳細解釋，感興趣的讀者可以閱讀《程序員的自我修養》這本書。
預處理
最后簡單描述一下預處理。預處理主要是處理一些宏定義，比如#define、#include、#if 等。預處理的實現有很多種，有的編譯器會在詞法分析前先進行預處理，替換掉所有 # 開頭的宏，而有的編譯器則是在詞法分析的過程中進行預處理。當分析到 # 開頭的單詞時才進行替換。雖然先預處理再詞法分析比較符合直覺，但在實際使用中，GCC 使用的卻是一邊詞法分析，一邊預處理的方案。
編譯 VS 解釋
總結一下，對于 C 語言來說，從源碼到運行結果大致上需要經歷編譯、匯編和鏈接三個步驟。編譯器接收源代碼，輸出目標代碼(也就是匯編代碼)，匯編器接收匯編代碼，輸出由機器碼組成的目標文件(二進制格式，.o 后綴)，最后鏈接器將各個目標文件鏈接起來，執行重定位，最終生成可執行文件。
編譯器以中間代碼為界限，又可以分前端和后端。比如 clang 就是一個前端工具，而 LLVM 則負責后端處理。另一個知名工具 GCC(GNU Compile Collection)則是一個套裝，包攬了前后端的所有任務。前端主要負責預處理、詞法分析、語法分析，最終生成語言無關的中間代碼。后端主要負責目標代碼的生成和優化。
關于編譯原理的基礎知識雖然枯燥，但掌握這些知識有助于我們理解一些有用的，但不太容易理解的概念。接下來，我們簡單看一下別的語言是如何運行的。
Java
在 Java 代碼的執行過程中，可以簡單分為編譯和執行兩步。Java 的編譯器首先會把 .java 格式的源碼編譯成 .class 格式的字節碼。字節碼對應到 C 語言的編譯體系中就是中間碼，Java 虛擬機執行這些中間碼得到最終結果。
回憶一下上文對中間碼的解釋，一方面它與語言無關，僅僅描述客觀事實。另一方面它和目標代碼的差距并不大，已經包括了對寄存器和棧的處理，僅僅是抽象了 CPU 架構而已，只要把它具體化成各個平臺下的目標代碼，就可以交給匯編器了。
解釋型語言
一般來說我們也把解釋型語言叫做腳本語言，比如 Python、Ruby、JavaScript 等等。這類語言的特點是，不需要編譯，直接由解釋器執行。換言之，運行流程變成了:
源代碼 -> 解釋器 -> 運行結果
需要注意的是，這里的解釋器只是一個黑盒，它的實現方式可以是多種多樣的。舉個例子，它的實現可以非常類似于 Java 的執行過程。解釋器里面可以包含一個編譯器和虛擬機，編譯器把源碼轉化成 AST 或者字節碼(中間代碼)然后交給虛擬機執行，比如 Ruby 1.9 以后版本的官方實現就是這個思路。
至于虛擬機，它并不是什么黑科技，它的內部可以編譯執行，也可以解釋執行。如果是編譯執行，那么它會把字節碼編譯成當前 CPU 下的機器碼然后統一執行。如果是解釋執行，它會逐條翻譯字節碼。
有意思的是，如果虛擬機是編譯執行的，那么這套流程和 C 語言幾乎一樣，都滿足下面這個流程:
源代碼 -> 中間代碼 -> 目標代碼 -> 運行結果
下面是重點!!!
下面是重點!!!
下面是重點!!!
因此，解釋型語言和編譯型語言的根本區別在于，對于用戶來說，到底是直接從源碼開始執行，還是從中間代碼開始執行。以 C 語言為例，所有的可執行程序都是二進制文件。而對于傳統意義的 Python 或者 JavaScript，用戶并沒有拿到中間代碼，他們直接從源碼開始執行。從這個角度來看， Java 不可能是解釋型語言，雖然 Java 虛擬機會解釋字節碼，但是對于用戶來說，他們是從編譯好的 .class 文件開始執行，而非源代碼。
實際上，在 x86 這種復雜架構下，二進制的機器碼也不能被硬件直接執行，CPU 會把它翻譯成更底層的指令。從這個角度來說，我們眼中的硬件其實也是一個虛擬機，執行了一些“抽象”指令，但我相信不會有人認為 C 語言是解釋型語言。因此，有沒有虛擬機，虛擬機是不是解釋執行，會不會生成中間代碼，這些都不重要，重要的是如果從中間代碼開始執行，而且 AST 已經事先生成好，那就是編譯型的語言。
如果更本質一點看問題，根本就不存在解釋型語言或者編譯型語言這種說法。已經有人證明，如果一門語言是可以解釋的，必然可以開發出這門語言的編譯器。反過來說，如果一門語言是可編譯的，我只要把它的編譯器放到解釋器里，把編譯推遲到運行時，這么語言就可以是解釋型的。事實上，早有人開發出了 C 語言的解釋器:
C 源代碼 -> C 語言解釋器(運行時編譯、匯編、鏈接) -> 運行結果
我相信這一點很容易理解，規范和實現是兩套分離的體系。我們平常說的 C 語言的語法，實際上是一套規范。理論上來說每個人都可以寫出自己的編譯器來實現 C 語言，只要你的編譯器能夠正確運行，最終的輸出結果正確即可。而編譯型和解釋型說的其實是語言的實現方案，是提前編譯以獲得最大的性能提高，還是運行時去解析以獲得靈活性，往往取決于語言的應用場景。所以說一門語言是編譯型還是解釋型的，這會非常可笑。一個標準怎么可能會有固定的實現呢?之所以給大家留下了 C 語言是編譯型語言，Python 是解釋型語言的印象，往往是因為這門語言的應用場景決定了它是主流實現是編譯型還是解釋型。
自舉
不知道有沒有人思考過，C 語言的編譯器是如何實現的?實際上它還是用 C 語言實現的。這種自己能編譯自己的神奇能力被稱為自舉(Bootstrap)。
乍一看，自舉是不可能的。因為 C 語言編譯器，比如 GCC，要想運行起來，必定需要 GCC 的編譯器將它編譯成二進制的機器碼。然而 GCC 的編譯器又如何編譯呢……
解決問題的關鍵在于打破這個循環，我們可以先用一個比 C 語言低級的語言來實現一個 C 語言編譯器。這件事是可能做到的，因為這個低級語言必然會比 C 語言簡單，比如我們可以直接用匯編代碼來寫 C 語言的編譯器。由于越低級的語言越簡單，但表達能力越弱，所以用匯編來寫可能太復雜。這種情況下我們可以先用一個比 C 語言低級但比匯編高級的語言來實現 C 語言的編譯器，同時用匯編來實現這門語言的編譯器。總之就是不斷用低級語言來寫高級語言的編譯器，雖然語言越低級，它的表達能力越弱，但是它要解析的語言也在不斷變簡單，所以這件事是可以做到的。
有了低級語言寫好的 C 語言編譯器以后，這個編譯器是二進制格式的。此時就可以刪掉所有的低級語言，只留一個二進制格式的 C 語言編譯器，接下來我們就可以用 C 語言寫編譯器，再用這個二進制格式的編譯器去編譯 C 語言實現的 C 語言編譯器了，于是完成了自舉。
以上邏輯描述起來比較繞，但我想多讀幾遍應該可以理解。如果實在不理解也沒關系，我們只要明白 C 語言可以自舉是因為它可以編譯成二進制機器碼，只要用低級語言生成這個機器碼，就不再需要低級語言了，因為機器碼可以直接被 CPU 執行。
從這個角度來看，解釋型語言是不可能自舉的。以 Python 為例，自舉要求它能用 Python 語言寫出來 Python 的解釋器，然而這個解釋器如何運行呢，最終還是需要一個解釋器。而解釋器體系下， Python 都是從源碼經過解釋器執行，又不能留下什么可以直接被硬件執行的二進制形式的解釋器文件，自然是沒辦法自舉的。然而，就像前面說的，Python 完全可以實現一個編譯器，這種情況下它就是可以自舉的。
所以一門語言能不能自舉，主要取決于它的實現形式能否被編譯并留下二進制格式的可執行文件。
運行時
本文的讀者如果是使用 Objective-C 的 iOS 開發者，想必都有過在面試時被 runtime 支配的恐懼。然而，runtime 并非是 Objective-C 的專利，絕大多數語言都有這個概念。所以有人說 Objective-C 具有動態性是因為它有 runtime，這種說法并不準確，我覺得要把 Objective-C 的 runtime 和一般意義的運行時庫區分開，認識到它僅僅是運行時庫的一個組成部分，同時還是要深入到方法調用的層面來談。
運行時庫的基本概念
以 C 語言為例，有非常多的操作最終都依賴于 glibc 這個動態鏈接庫。包括但不限于字符串處理(strlen、strcpy)、信號處理、socket、線程、IO、動態內存分屏(malloc)等等。這一點很好理解，如果回憶一下之前編譯器的工作原理，我們會發現它僅僅是處理了語言的語法，比如變量定義，函數聲明和調用等等。至于語言的功能， 比如內存管理，內建的類型，一些必要功能的實現等等。如果要對運行時庫進行分類，大概有兩類。一種是語言自身功能的實現，比如一些內建類型，內置的函數;另一種則是語言無關的基礎功能，比如文件 IO，socket 等等。
由于每個程序都依賴于運行時庫，這些庫一般都是動態鏈接的，比如 C 語言的 (g)libc。這樣一來，運行時庫可以存儲在操作系統中，節省內存占用空間和應用程序大小。
對于 Java 語言來說，它的垃圾回收功能，文件 IO 等都是在虛擬機中實現，并提供給 Java 層調用。從這個角度來看，虛擬機/解釋器也可以被看做語言的運行時環境(庫)。
swift 運行時庫
經過這樣的解釋，相信 swift 的運行時庫就很容易理解了。一方面，swift 是絕對的靜態語言，另一方面，swift 毫無疑問的帶有自己的運行時庫。舉個最簡單的例子，如果閱讀 swift 源碼就會發現某些類型，比如字符串(String)，或者數組，再或者某些函數(print)都是用 swift 實現的，這些都是 swift 運行時庫的一部分。按理說，運行時庫應該內置于操作系統中并且和應用程序動態鏈接，然而坑爹的 Swift 在本文寫作之時依然沒有穩定 ABI，導致每個程序都必須自帶運行時庫，這也就是為什么目前 swift 開發的 app 普遍會增加幾 Mb 包大小的原因。
說到 ABI，它其實就是一個編譯后的 API。簡單來說，API 是描述了在應用程序級別，模塊之間的調用約定。比如某個模塊想要調用另一個模塊的功能，就必須根據被調用模塊提供的 API 來調用，因為 API 中規定了方法名、參數和返回結果的類型。而當源碼被編譯成二進制文件后，它們之間的調用也存在一些規則和約定。
比如模塊 A 有兩個整數 a 和 b，它們的內存布局如下:
| 初始地址 |
| a |
| b |
這時候別的模塊調用 A 模塊的 b 變量，可以通過初始地址加偏移量的方式進行。
如果后來模塊 A 新增了一個整數 c，它的內存布局可能會變成:
| 初始地址 |
| c |
| a |
| b |
如果調用方還是使用相同的偏移量，可以想見，這次拿到的就是變量 a 了。因此，每當模塊 A 有更新，所有依賴于模塊 A 的模塊都必須重新編譯才能正確工作。如果這里的模塊 A 是 swift 的運行時庫，它內置于操作系統并與其他模塊(應用程序)動態鏈接會怎么樣呢?結果就是每次更新系統后，所有的 app 都無法打開。顯然這是無法接受的。
當然，ABI 穩定還包括其他的一些要求，比如調用和被調用者遵守相同的調用約定(參數和返回值如何傳遞)等。
JavaScript 那些事
我們繼續剛才有關運行時的話題，先從 JavaScript 的運行時聊起，再介紹 JavaScript 的相關知識。
JavaScript 是如何運行的
JavaScript 和其他語言，無論是 C 語言，還是 Python 這樣的腳本語言，最大的區別在于 JavaScript 的宿主環境比較奇怪，一般來說是瀏覽器。
無論是 C 還是 Python，他們都有一個編譯器/解釋器運行在操作系統上，直接把源碼轉換成機器碼。而 JavaScript 的解釋器一般內置在瀏覽器中，比如 Chrome 就有一個 V8 引擎可以解析并執行 JavaScript 代碼。因此 JavaScript 的能力實際上會受到宿主環境的影響，有一些限制和加強。
首先來看看 DOM 操作，相關的 API 并沒有定義在 ECMAScript 標準中，因此我們常用的 window.xxx 還有 window.document.xxx 并非是 JavaScript 自帶的功能，這通常是由宿主平臺通過 C/C++ 等語言實現，然后提供給 JavaScript 的接口。同樣的，由于瀏覽器中的 JavaScript 只是一個輕量的語言，沒有必要讀寫操作系統的文件，因此瀏覽器引擎一般不會向 JavaScript 提供文件讀寫的運行時組件，它也就不具備 IO 的能力。從這個角度來看，整個瀏覽器都可以看做 JavaScript 的虛擬機或者運行時環境。
因此，當我們換一個宿主環境，比如 Node.js，JavaScript 的能力就會發生變化。它不再具有 DOM API，但多了讀寫文件等能力。這時候，Node.js 就更像是一個標準的 JavaScript 解析器了。這也是為什么 Node.js 讓 JavaScript 可以編寫后端應用的原因。
JIT 優化
解釋執行效率低的主要原因之一在于，相同的語句被反復解釋，因此優化的思路是動態的觀察哪些代碼是經常被調用的。對于那些被高頻率調用的代碼，可以用編譯器把它編譯成機器碼并且緩存下來，下次執行的時候就不用重新解釋，從而提升速度。這就是 JIT(Just-In-Time) 的技術原理。
但凡基于緩存的優化，一定會涉及到緩存命中率的問題。在 JavaScript 中，即使是同一段代碼，在不同上下文中生成的機器碼也不一定相同。比如這個函數:
如果這里的 a 和 b 都是整數，可以想見最終的代碼一定是匯編中的 add 命令。如果類似的加法運算調用了很多次，解釋器可能會認為它值得被優化，于是編譯了這段代碼。但如果下一次調用的是 add("hello", "world")，之前的優化就無效了，因為字符串加法的實現和整數加法的實現完全不同。
于是優化后的代碼(二進制格式)還得被還原成原先的形式(字符串格式)，這樣的過程被稱為去優化。反復的優化 -> 去優化 -> 優化 …… 非常耗時，大大降低了引入 JIT 帶來的性能提升。
JIT 理論上給傳統的 JavaScript 帶了了 20-40 倍的性能提升，但由于上述去優化的存在，在實際運行的過程中遠遠達不到這個理論上的性能天花板。
WebAssembly
前文說過，JavaScript 實際上是由瀏覽器引擎負責解析并提供一些功能的。瀏覽器引擎可能是由 C++ 這樣高效的語言實現的，那么為什么不用 C++ 來寫網頁呢?實際上我認為從技術角度來說并不存在問題，直接下發 C++ 代碼，然后交給 C++ 解釋器去執行，再調用瀏覽器的 C++ 組件，似乎更加符合直覺一些。
之所以選擇 JavaScript 而不是 C++，除了主流瀏覽器目前都只支持 JavaScript 而不支持 C++ 這個歷史原因以外，更重要的一點是一門語言的高性能和簡單性不可兼得。JavaScript 在運行速度方面做出了犧牲，但也具備了簡單易開發的優點。作為通用編程語言，JavaScript 和 C++ 主要的性能差距就在于缺少類型標注，導致無法進行有效的提前編譯。之前說過 JIT 這種基于緩存去猜測類型的方式存在瓶頸，那么最精確的方式肯定還是直接加上類型標注，這樣就可以直接編譯了，代表性的作品有 Mozilla 的Asm.js。
Asm.js 是 JavaScript 的一個子集，任何 JavaScript 解釋器都可以解釋它:
如果有 Asm.js 特定的解釋器，完全可以把它提前編譯出來。即使沒有也沒關系，因為它完全是 JavaScript 語法的子集，普通的解釋器也可以解釋。
然而，回顧一下我們最初對解釋器的定義: 解釋器是一個黑盒，輸入源碼，輸出運行結果。Asm.js 其實是黑盒內部的一個優化，不同的黑盒(瀏覽器)無法共享這一優化。換句話說 Asm.js 寫成的代碼放到 Chrome 上面和普通的 JavaScript 毫無區別。
于是，包括微軟、谷歌和蘋果在內的各大公司覺得，是時候搞個標準了，這個標準就是 WebAssembly 格式。它是介于中間代碼和目標代碼之間的一種二進制格式，借用WebAssembly 系列(四)WebAssembly 工作原理 一文的插圖來表示:
通常從中間代碼到機器碼，需要經過平臺具體化(轉目標代碼)和二進制化(匯編器把匯編代碼變為二進制機器碼)這兩個步驟。而 WebAssembly 首先完成了第二個步驟，即已經是二進制格式的，但只是一系列虛擬的通用指令，還需要轉換到各個 CPU 架構上。這樣一來，從 WebAssembly 到機器碼其實是透明且統一的，各個瀏覽器廠商只需要考慮如何從中間代碼轉換 WebAssembly 就行了。
由于編譯器的前端工具 Clang 可以把 C/C++ 轉換成中間代碼，因此理論上它們都可以用來開發網頁。然而誰會這么這么做呢，放著簡單快捷，現在又高效的 JavaScript 不寫，非要去啃 C++?
跨語言那些事兒
C++ 寫網頁這個腦洞雖然比較大，但它啟發我思考一個問題:“對于一個常見的可以由某個語言完成的任務(比如 JavaScript 寫網頁)，能不能換一個語言來實現(比如 C++)，如果不能，制約因素在哪里”。
由于絕大多數主流語言都是圖靈完備的，也就是說一切可計算的問題，在這些語言層面都是等價的，都可以計算。那么制約語言能力的因素也就只剩下了運行時的環境是否提供了相應的功能。比如前文解釋過的，雖然瀏覽器中的 JavaScript 不能讀寫文件，不能實現一個服務器，但這是瀏覽器(即運行時環境)不行，不是 JavaScript 不行，只要把運行環境換成 Node.js 就行了。
直接語法轉換
大部分讀者應該接觸過簡單的逆向工程。比如編譯后的 .o 目標文件和 .class 字節碼都可以反編譯成源代碼，這種從中間代碼倒推回源代碼的技術也被叫做反編譯(decompile)，反編譯器的工作流程基本上是編譯器的倒序，只不過完美的反編譯一般來說比較困難，這取決于中間代碼的實現。像 Java 字節碼這樣的中間代碼，由于信息比較全，所以反編譯就相對容易、準確一些。C 代碼在生成中間代碼時丟失了很多信息，因此就幾乎不可能 100% 準確的倒推回去，感興趣的讀者可以參考一下知名的反編譯工具Hex-Rays 的一篇博客。
前文說過，編譯器前端可以對多種語言進行詞法分析和語法分析，并且生成一套語言無關的中間代碼，因此理論上來說，如果某個編譯器前端工具支持兩個語言 A 和 B 的解析，那么 A 和 B 是可以互相轉換的，流程如下:
A 源碼 <--> 語言無關的中間代碼 <--> B 源碼
其中從源碼轉換到中間代碼需要使用編譯器，從中間代碼轉換到源碼則使用反編譯器。
但在實際情況中，事情會略復雜一些，這是因為中間代碼雖然是一套語言無關、CPU 也無關的指令集，但不代表不同語言生成的中間代碼就可以通用。比如中間代碼共有 1、2、3、……、6 這六個指令。A 語言生成的中間代碼僅僅是所有指令的一個子集，比如是 1-5 這 5 個指令;B 語言生成的中間代碼可能是所有指令的另一個子集，比如 2-6。這時候我們說的 B 語言的反編譯器，實際上是從 2-6 的指令子集推導出 B 語言源碼，它對指令 1 可能無能為力。
以 GCC 的中間代碼 RTL: Register Transfer Language 為例，官方文檔 在對 RTL 的解釋中，就明確的把 RTL 樹分為了通用的、C/C++ 特有的、Java 特有的等幾個部分。
具體來說，我們知道 Java 并不能直接訪問內存地址，這一點和瀏覽器上的 JavaScript 不能讀寫文件很類似，都是因為它們的運行環境(虛擬機)具備這種能力，但沒有在語言層面提供。因此，含有指針四則運算的 C 代碼無法直接被轉換成 Java 代碼，因為 Java 字節碼層面并沒有定義這樣的抽象，一種簡單的方案是申請一個超大的數組，然后自己模擬內存地址。
所以，即使編譯器前端同時支持兩種語言的解析，要想進行轉換，還必須處理兩種語言在中間代碼層面的一些小差異，實際流程應該是:
A 源碼 <--> 中間代碼子集(A) <--適配器--> 中間代碼子集(B) <--> B 源碼
這個思路已經不僅僅停留在理論上了，比如 Github 上有一個庫: emscripten 就實現了將任何 Clang 支持的語言(比如 C/C++ 等)轉換成 JavaScript，再比如 lljvm實現了 C 到 Java 字節碼的轉換。
然而前文已經解釋過，實現單純語法的轉換意義并不大。一方面，對于圖靈完備的語言來說，換一種表示方法(語言)去解決相同的問題并沒有意義。另一方面，語言的真正功能絕不僅僅是語法本身，而在于它的運行時環境提供了什么樣的功能。比如 Objective-C 的 Foundation 庫提供了字典類型 NSDictionary，它如果直接轉換成 C 語言，將是一個找不到的符號。因為 C 語言的運行時環境根本就不提供對這種數據結構的支持。因此凡是在語言層面進行強制轉換的，要么利用反編譯器拿到一堆格式正確但無法運行的代碼，要么就自行解析語法樹并為轉換后的語言添加對應的能力，來實現轉換前語言的功能。
比如圖中就是一個 C 語言轉換 Java 的工具，為了實現 C 語言中的字符串申請和釋放內存，這個工具不得不自己實現了 com.mtsystems.coot.String8 類。這樣巨大的成本，顯然不夠普適，應用場景相對有限。
總之，直接的語法轉換是一個美好的想法，但實現起來難度大，收益有限，通常是為了移植已經用某個語言寫好的框架，或者開個腦洞用于學習，但實際應用場景并不多。
膠水語言 Python
Python 一個很強大的特點是膠水語言，可以把 Python 理解為各種語言的粘合劑。對于 Python 可以處理的邏輯，用 Python 代碼即可完成。如果追求極致的性能或者調用已經實現的功能，也可以讓 Python 調用已經由別的語言實現的模塊，以 Python 和 C 語言的交互解釋一下。
首先，如果是 C 語言要執行 Python 代碼，顯然需要一個 Python 的解釋器。由于在 Mac OS X 系統上，Python 解釋器是一個動態鏈接庫，所以只要導入一下頭文件即可，下面這段代碼可以成功輸出 “Hello Python!!!”:
如果是在 iOS 應用里，由于 iOS 系統沒有對應的動態庫，所以需要把 Python 的解釋器打包成一個靜態庫并且鏈接到應用中，網上已經有人做好了: python-for-iphone，這就是為什么我們看到一些教育類的應用模擬了 Python 解釋器，允許用戶編寫 Python 代碼并得到輸出。
Python 調用 Objective-C/C 也不復雜，只需要在 C 代碼中指定要暴露的模塊 A 和要暴露的方法 a，然后 Python 就可以直接調用了:
詳細的教程可以看這里: 如何實現 C/C++ 與 Python 的通信?
有時候，如果能把自己熟悉的語言應用到一個陌生的領域，無疑會大大降低上手的難度。以 iOS 開發為例，開發者的日常其實是利用 Objective-C 語法來描述一些邏輯，最終利用 UIKit 等框架完成和應用的交互。 一種很自然而然的想法是，能不能用 Python 來實現邏輯，并且調用 Objective-C 的接口，比如 UIKit、Foundation 等。實際上前者是完全可以實現的，但是 Python 調用 Objective-C 遠比調用 C 語言要復雜得多。
一方面從之前的分析中也能看出，并不是所有的源碼編譯成目標文件都可以被 Python 引用;另一方面，最重要的是 Objective-C 方法調用的特性。我們知道方法調用實際上會被編譯成 msg_Send 并交給 runtime 處理，最終找到函數指針并調用。這里 Objective-C 的 runtime 其實是一個用 C 語言實現動態鏈接庫，它可以理解為 Objective-C 運行時環境的一部分。換句話說，沒有 runtime 這個庫，包含方法調用的 Objective-C 代碼是不可能運行起來的，因為 msg_Send 這個符號無法被重定向，運行時將找不到 msg_Send 函數的地址。就連原生的 Objective-C 代碼都需要依賴運行時，想讓 Python 直接調用某個 Objective-C 編譯出來的庫就更不可能了。
想用 Python 寫開發 iOS 應用是有可能的，比如: PyObjc，但最終還是要依賴 Runtime。大概的思路是首先用 Python 拿到 runtime 這個庫，然后通過這個庫去和 runtime 交互，進而具備了調用 Objective-C 和各種框架的能力。比如我要實現 Python 中的 UIView 這個類，代碼會變成這樣:
這么做的性價比并不高，如果和 JSPatch 相比，JSPatch 使用了內置的 JavaScriptCore 作為 JavaScript 的解析器，而 PyObjc 就得自己帶一個 libPython.a 解釋器。此外，由于 iOS 系統的沙盒限制，非越獄機器并不能拿到 libobjc 庫，所以這個工具只能在越獄手機上使用。
OCS
既然說到了 JSPatch 這一類動態化的 iOS 開發工具，我就斗膽猜測一下騰訊 OCS 的實現原理，目前介紹 OCS 的文章寥寥無幾，由于蘋果公司的要求，原文已經被刪除，從新浪博客上摘錄了一份: OCS ——史上最瘋狂的 iOS 動態化方案。如果用一句話來概述，那么就是 OCS 是一個 Objective-C 解釋器。
首先，OCS 基于 clang 對下發的 Objective-C 代碼做詞法、語法分析，生成 AST 然后轉化成自定義的一套中間碼(OSScript)。當然，原生的 Objective-C 可以運行，絕不僅僅是編譯器的功勞。就像之前反復強調的那樣，運行時環境也必不可少，比如負責 GCD 的 libdispatch 庫，還有內存管理，多線程等等功能。這些功能原來都由系統的動態庫實現，但現在必須由解釋器實現，所以 OCS 的做法是開發了一套自己的虛擬機去解釋執行中間碼。這個運行原理就和 JVM 非常類似了。
當然，最終還是要和 Objective-C 的 Runtime 打交道，這樣才能調用 UIKit 等框架。由于對虛擬機的實現原理并不清楚，這里就不敢多講了，希望在學習完 JVM 以后再做分享。
參考資料
轉載于:https://www.cnblogs.com/jacksplwxy/p/10807114.html
總結
以上是生活随笔為你收集整理的大前端开发者需要了解的基础编译原理和语言知识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件工程第二次结对作业
- 下一篇： 【剑指Offer】28、数组中出现次数超