作為挪動開發(fā)你不能不理解的編譯流程

C/C++ 從0到1系統精講 項目開發(fā)綜合基礎K

download：https://www.51xuebc.com/thread-543-1-1.html

閱讀本文，或許可以理解關于以下的幾個問題： 1、編譯器是什么？為什么會有編譯器這樣一個東西？ 2、編譯器做了哪些工作？整個編譯過程又是什么？ 3、Apple的編譯器開展進程以及為什么會丟棄GCC換成自研的LLVM？ 4、從編譯器角度看Swift與OC可以完成混編的底層邏輯

一、找個翻譯官，說點計算機能懂的言語
說點常識，眾所周知，作為開發(fā)者我們能看懂這樣的代碼：

int a = 10;
int b = 20;
int c = a + b;
而關于計算機貌似只能明白這樣的內容:

注：運用 od -tx1 /tmp/binary.bin 能夠依據需求輸出二進制、八進制或者十六進制的內容

這樣看的話，計算機除了曉得1與0的含義，其他的字符內容完整不曉得。為了去給計算機下達我們需求的指令，我們又不得不得依照計算機可以懂得言語與其停止通訊交流，怎樣辦呢？我們貌似需求找一個翻譯，將我們的想要下達的指令內容交給翻譯讓其成計算機可以辨認的指令停止內容傳達，這樣計算機就能經過翻譯來一步步執(zhí)行我們的指令動作了，那這個翻譯其實就是我們經常說到的編譯器。

說到編譯器呢？它的歷史還是很長久的，早期的計算機軟件都是用匯編言語直接編寫的，這種情況持續(xù)了數年。當人們發(fā)現為不同類型的中央處置器CPU編寫可重用軟件的開支要明顯高于編寫編譯器時，人們創(chuàng)造了高級編程言語。簡單說就是由于中央處置器CPU的差別，使得軟件的開發(fā)本錢很高，我們要針對不同的CPU編寫不同的匯編代碼，而且不同的CPU架構呢相對應的匯編的指令集也有差別。假如在匯編體系之上定義一套與匯編無關的編碼言語，經過對通用的這樣言語停止轉換，將其轉換成不同類型的CPU的匯編指令，是不是就能處理不同CPU架構適配的問題呢？那其中的定義的通用編碼言語就是我們所說的高級言語，比方C/C++、Object-C、Swift、Java等等，而其中的匯編翻譯轉換工作呢則交由詳細的編譯器停止完成。

二、說到編譯器當然少不了Apple
關于Apple的編譯器，就不得不說一下GCC與LLVM的相愛相殺了。由于編譯器觸及到從高級開發(fā)言語到低級言語的轉換處置，復雜度自然不用多說。我們都曉得Apple產品軟件的開發(fā)言語是Objective-C，能夠以為是對C言語的擴展。而C言語所運用的編譯器則是大名鼎鼎的GCC，此時的GCC肯定是妥妥的大哥了，所以早些年為了不用要的資源投入，關于自家OC（Objective-C簡稱OC）編譯器的開發(fā)索性直接拿大哥的代碼GCC停止二次開發(fā)了，沒錯，從主干版本中拉個獨立分支搞起。這么看的話，Apple早期就曾經開端了降本增效了？

隨著OC言語的不時迭代開展，言語特性也就愈來愈多，那編譯器的新特性才能支持當然也得跟得上??？但是C也在不時的迭代開展，GCC編譯器的主干功用當然也越來越多，OMG！單獨維護的OC編譯器版本對GCC主干的新功用并沒有很好的同步，關鍵在兼并功用的時分不可防止的呈現種種抵觸。為此，Apple曾屢次申請與GCC主干功用兼并同步，GCC乍一看都是OC 特性feature，跟C有毛線關系？所以關于兼并的優(yōu)先級總是排到最低，Apple也是沒有方法，結果只能是差別化的東西越來越多，編譯器的維護本錢也變得異常之高。



除了以上的問題之外，GCC整體的架構設計也是非模塊化的，那什么是模塊化呢？比方我們通常在系統設計的時分，會將各個系統的功用停止模塊化分割設計，不同的模塊可以單獨為系統內部提供不同的功用。同時呢，我們還能把這些模塊單獨抽離出來提供應外部運用，這就增大了系統的底層的靈敏度，簡單說就是可以直接運用模塊化的接口才能。



所以Apple深知定制化的GCC編譯器將是后續(xù)言語迭代晉級的絆腳石，內部也在不時的探究可以替代GCC的替代品。在編譯器的探究路上，這里不得不說一下Apple的一位神級工程師 Chris Lattner(克里斯·拉特納)，可能光說名字的話可能沒有太多人曉得他，那假如要說Swift言語的開創(chuàng)人是不是就有所耳聞了？由于克里斯在大學期間對編譯器的細致的研討，發(fā)起了LLVM（Low Level Virtual Machine）項目對編譯的源代碼停止了整體的優(yōu)化。Apple將眼光放在了克里斯團隊身上，同時直接顧用了他們團隊，當然克里斯也沒有孤負眾望，在 Xcode從 3.1完成了llvm-gcc compiler，到 3.2完成了Clang 1.0， 再到4.0完成了Clang 2.0 ，后來在Mac OS X 10.6 開端運用LLVM的編譯技術，到如今曾經將LLVM開展成為了Apple的中心編譯器。



三、LLVM編譯器的編譯過程與特性
關于傳統的編譯器，主要分為前端、優(yōu)化器和后端，援用一張通用的簡約的編譯過程圖，如下：



簡單來說，針關于源代碼翻譯成計算機底層代碼的過程中呢要閱歷三個階段：前端編譯、優(yōu)化器優(yōu)化、后端編譯。經過前端編譯之后，針對編譯的產物停止優(yōu)化處置，最后經過后端完成機器碼的生成。而關于LLVM編譯器來說，這里我們以OC的前端編譯器Clang為例，它擔任LLVM的前端的整體編譯流程（預處置、詞法剖析、語法剖析和語義剖析），生成中間產物LLVMIR，最后由后端停止架構處置生成目的代碼，如下圖：



能夠看出LLVM將編譯的前后端獨立分開了，前端擔任不同言語的編譯操作，假如增加一個言語的編譯支持，只需求擴展支持當前言語的前端編譯支持（Clang擔任OC前端編譯、SwiftC擔任Swift前端編譯）即可，優(yōu)化器與后端編譯器整體均不用修正即可完成新增言語的支持。同理，關于后端，假如需求新增新的架構設備的支持，只需求擴展后端架構對應編譯器的支持即可完成新架構設備的支持，這也是LLVM編譯器的優(yōu)點之一。



3.1、編譯器前端
在XCode中針關于OC與Swift的編譯有著不同的前端編譯器，OC采用Clang停止編譯，而Swift則采用SwiftC編譯器，兩種不同的編譯器前端在編譯之后，生成的中間產物都是LLVMIR。這也就解釋了關于高級言語Swift或者OC開發(fā)，哪怕是混編，在經過各自的編譯器前端編譯之后，最終的編譯產物都是一樣的，所以選用哪種開發(fā)言語關于最終生成的中間代碼IR都是通用的。關于Clang的整體編譯過程，如下圖所示：



預處置
經過對源代碼中以“#”號開頭如包含#include，宏定義制定#define等掃描。然后停止源代碼定義交換，停止頭文件內容的展開。經過預處置器把源文件處置成.i文件。

詞法剖析
在詞法剖析完成之后會生成 token 產物，它是做什么的？這里不貼官方的解釋了，簡單點說就是對源代碼的原子切分，切分紅可以底層描繪的單個原子，就是所謂的token，至于token長什么樣子？能夠經過 clang 的命令執(zhí)行編譯查看生成的原子內容：

clang -fmodules -E -Xclang -dump-tokens xxx.m
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char * argv[]) {
NSString * appDelegateClassName;
@autoreleasepool {
// Setup code that might create autoreleased objects goes here.
appDelegateClassName = NSStringFromClass([AppDelegate class]);
int a = 0;
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
我們拿工程的main.m 做個測試，編譯生成的內容如下：



注：假如遇到 main.m:8:9: fatal error: 'UIKit/UIKit.h' file not found 錯誤，能夠加上系統根底庫途徑如下：

clang \
-fmodules \
-E \
-Xclang \
-dump-tokens \
-isysroot \
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk \
main.m
能夠發(fā)現，計算機在停止源碼處置的時分，并不能像人一樣可以了解整個源碼內容的含義。所以為了停止轉換，在停止源碼剖析的時分，將整體的內容停止單詞切分，構成原子為后續(xù)的語義剖析做準備，整體的切分過程大致采用的是狀態(tài)機原理。

語法剖析
在完成詞法剖析之后，編譯器大致了解了每個源碼中的單詞的意義，但是關于單詞組合起來的語句內容并不能了解。所以接下來需求對單詞組合起來的內容停止辨認，也就是我們所說的**語法剖析**。 語法剖析的原理有點模板匹配的意義，怎樣了解呢？就是我們常說的語法規(guī)則，在編譯器中預置了相關言語的語法規(guī)則模板，假如匹配了相關的規(guī)則，則依照相關語法規(guī)則停止解析。舉個例子，比方我們在OC中寫一個這樣的語句：

int a = 100;
這是一種通用的賦值語法格式，所以在編譯器停止語法剖析的時分，將其依照賦值語法的規(guī)則停止解析，如下：



經過對原子token的組合解析，最終會生成了一個籠統語法樹（AST），AST籠統語法樹將源代碼轉換成樹狀的數據構造，它描繪了源代碼的內容含義以及內容構造，它的生成可以讓計算機更好的了解和處置中間產物。以XCode生成的默許項目的main.m內容為例，在 clang 中我們照舊能夠查看詳細的籠統生成樹（AST）的樣子，能夠對源碼停止如下的編譯：

clang \
-isysroot \
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk \
-fmodules \
-fsyntax-only \
-Xclang \
-ast-dump \
main.m
編譯后的結果如下：



簡單轉換一下樹形視圖，大致長這樣：



能夠發(fā)現，閱歷過語法剖析之后，源代碼轉換成了詳細的數據構造，而數據構造的整體生成是后續(xù)停止語義剖析生成中間代碼的根底前提。

語義剖析
在閱歷過語法剖析之后，編譯器會對語法剖析之后生成的籠統語法樹（AST）再次停止處置，需求留意的是編譯器并不會直接經過AST編譯成目的代碼，主要緣由是由于編譯器將編譯過程拆分了前后端，而前后端的通訊的媒介就是IR，沒錯就是之前提到過的LLVMIR這樣一個中間產物。該中間產物與言語無關，同時與cpu的架構也無關，那么為什么要加上中間產物這個環(huán)節(jié)，直接生成目的代碼難道不是更好嗎？我們都曉得cpu的不同架構直接影響cpu的指令集，不同的指令集對應不同的匯編指令，所以針關于不同的cpu架構要對應生成不同適配的匯編指令才干正常的運轉到不同的cpu架構的機器上。假如將前后端的編譯過程綁定死，那么就會招致每增加一個新的編譯前端，同時增加對一切cpu架構的后端的支持（1對n的關系），同理，假如增加新的一個cpu架構支持，編譯前端也需求統統再完成一遍，這個工作量是很反復以及繁瑣的。所以為了防止這樣的問題，Apple對編譯器的前后端停止了拆分，用中間產物來停止前后端的邏輯適配。

關于語義剖析生成中間產物的過程，也能夠經過 Clang 的編譯命令查看，詳細如下：

# 生成擴展為.ll的便于閱讀的文本格式
clang \
-isysroot \
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk \
-S \
-emit-llvm \
main.m \
-o \
main.ll
# 生成二進制格式，擴展為.bc
clang \
-isysroot \
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk \
-emit-llvm \
-c \
main.m \
-o \
main.bc
從編譯的產物來看，其中也包含了常見的內存分配、所用到的標識定義等內容，能夠明顯的發(fā)現生成的中間產物曾經沒有任何源代碼言語的影子了。同時我們會發(fā)現針關于中間代碼，存放器（%+數字）的運用仿佛沒有個數限制，為什么呢？由于中間代碼只是將源代碼停止了中間代碼的描繪轉義，此時并沒有相關的目的架構信息可供參考運用，所以針關于變量的援用也僅僅是中間層的標識。在后端編譯的過程中會將中間的這些存放器的援用再次停止指令的轉換，最終會生成對應CPU架構指令集的匯編代碼。

還記得XCode中的BitCode開關選項嗎？它決議了編譯生成的中間產物IR能否需求保管，假如保管的話，會把當前的中間產物插入到可執(zhí)行文件的數據段中，保存這些中間產物內容又有什么作用呢？我們曉得在沒有保存中間產物之前，為了確保一切cpu架構的機型可以正常裝置打出的裝置包，在打包的時分會把可以支持的一切cpu架構的匯合停止兼并打包，生成一個Fat Binary，確保裝置包可以適配一切的機型，這樣會有一個問題，比方ARM64架構的機器在裝置的時分只需求ARM64的架構二進制文件即可，但是由于裝置包里兼容了一切的cpu架構，其他的架構代碼實踐上基本沒有用到，這也就間接的招致了裝置包的體積變大。而蘋果在應用分發(fā)的時分，是曉得目的機器的cpu架構的，所以假如可以將中間的編譯產物交給AppStore后臺，由Appstore后臺經過編譯后端優(yōu)化生成目的機器的二進制可執(zhí)行文件，去除無用的兼容架構代碼，進而縮減裝置包的體積大小。這也即是BitCode的呈現目的，為理解決編譯架構冗余的問題，同時也為APP的瘦身提供參考。

編譯器在停止語義剖析期間還有一個重要的過程叫做靜態(tài)剖析（Static Analysis），llvm官方文檔是這樣引見靜態(tài)剖析的：

The term "static analysis" is conflated, but here we use it to mean a collection of algorithms and techniques used to analyze source code in order to automatically find bugs. The idea is similar in spirit to compiler warnings (which can be useful for finding coding errors) but to take that idea a step further and find bugs that are traditionally found using run-time debugging techniques such as testing.?

Static analysis bug-finding tools have evolved over the last several decades from basic syntactic checkers to those that find deep bugs by reasoning about the semantics of code. The goal of the Clang Static Analyzer is to provide a industrial-quality static analysis framework for analyzing C, C++, and Objective-C programs that is freely available, extensible, and has a high quality of implementation.

靜態(tài)剖析它可以協助我們在編譯期間自動查找錯誤，比起運轉時的時分去找出錯誤要更早一步，能夠用于剖析 C、C++ 和 Objective-C 程序。編譯器經過靜態(tài)剖析根據AST中節(jié)點與節(jié)點之間的關系，找出有問題的節(jié)點并拋出正告錯誤，到達修正提示的目的。比方官方文檔中引見的內存泄露的靜態(tài)剖析的案例：



除了官方的靜態(tài)剖析，我們常用的OCLint也是在編譯器生成AST籠統語法樹之后，對籠統語法樹停止遍歷剖析，到達校驗標準的目的，總結一下編譯前端的所閱歷的流程：經過源碼輸入，對源碼停止詞法剖析將源碼停止內容切割生成原子token。經過語法剖析對原子token的組合停止語法模板匹配，生成籠統語法樹（AST）。經過語義剖析，對籠統語法樹停止遍歷生成中間代碼IR與符號表信息內容。

3.2、編譯器后端
編譯器后端主要做了兩件重要的事情： 1、優(yōu)化中間層代碼LLVMIR（閱歷屢次的Pass操作） 2、生成匯編代碼，最終鏈接生成機器碼

編譯器前端完成編譯后，生成了相關的編譯產物LLVMIR，LLVMIR會經過優(yōu)化器停止優(yōu)化，優(yōu)化的過程會閱歷一個又一個的Pass操作，什么是Pass呢？援用官方的解釋：

The LLVM Pass Framework is an important part of the LLVM system, because LLVM passes are where most of the interesting parts of the compiler exist. Passes perform the transformations and optimizations that make up the compiler, they build the analysis results that are used by these transformations, and they are, above all, a structuring technique for compiler code.
我們能夠了解為一個個的中間過程的優(yōu)化，比方指令選擇、指令調度、存放器的分配等，輸入輸出也都是IR，如下圖：

在最終優(yōu)化完成之后，會生成一張DAG圖給到后端。我們曉得DAG是一張有向的非環(huán)圖，這個特性能夠用來標識硬件的特定次第，便當后端的內容處置。我們也能夠依據本人的需求經過繼承Pass來寫一些自定義的Pass用于自定義的優(yōu)化，官方關于自定義的Pass也有相關的闡明，感興味的同窗能夠去看看（鏈接放在本文最后了）。在經過優(yōu)化之后，后端根據不同架構的編譯器生成對應的匯編代碼，最終經過鏈接完成機器碼的整體生成。

四、編譯器讓計算機更懂人類
能夠發(fā)現編譯器是計算機高級言語的中梁砥柱，如今隨著高級言語的開展越來越疾速，向著簡單高效靈敏的方向不時行進，這里面與編譯器的開展有著親密的聯絡。同時隨著編譯器的開展晉級，讓高級言語到低級言語的轉換變得更高效，同時也為諸多的跨平臺言語完成提供了諸多可能。經過對計算機底層言語的層層籠統，降生了我們所熟知的計算機高級言語，讓我們可以用人類的思想邏輯停止指令輸入，而籠統的層層翻譯處置則交給了編譯器，它的存在樹立了人類與計算機溝通的重要橋梁。