此處已是系列博文的第二篇，你最好從頭開始看吧。

這篇文章會講解 Visual C++ 編譯器的數(shù)據(jù)流——首先會以一段C++源程序開始，以對應(yīng)的二進(jìn)制程序結(jié)束。這篇文章很簡單——一切才剛剛開始。

首先我們來看看從命令行開始，編譯一個單一文件的程序 APP.cpp 時會發(fā)生什么（如果你想從Vistual Studio 來啟動編譯，下圖還必須包含一些高層軟件，然而,結(jié)束時,它們會給出一些很特別的命令，我后面會講到）。

假設(shè)我們剛才鍵入了: CL/02 App.cpp

CL代表‘編譯和鏈接’，02告訴編譯器優(yōu)化速度—-生成一些執(zhí)行速度盡可能快的機器碼。該命令啟動一個進(jìn)程去運行CL.EXE程序—- 一個調(diào)用了其他軟件的驅(qū)動器：連接到一起時，他們會處理APP.cpp里的文本，最終生產(chǎn)一個二進(jìn)制文件，成為App.exe。 執(zhí)行時，該二進(jìn)制文件會執(zhí)行我們源代碼里的操作。

我們?yōu)g覽下上個圖表，看看發(fā)生了什么。

CL．EXE 解析我們的命令行，并檢查它是否有意義。然后調(diào)用位于C1XX.DLL的 C++‘前端’（“CXX”是指C++，因為以前‘+’不能用于文件名。）前端是用于理解C++語言的一條鏈。它掃描，解析并將APP.cpp文件轉(zhuǎn)換為 一顆等價樹，通過五個臨時文件傳遞給下一個組件。這五個文件被稱為CIL，意為C中間語言。不要把它跟托管語言，例如C#生產(chǎn)的中間代碼混淆。有時，也成 為MSIL，但是不幸的是，在ECMA-335標(biāo)準(zhǔn)里，它被命名為CIL。

接下來,CL.EXE會調(diào)用 所謂的‘后端’，位于C2.DLL。我們把后端成為‘UTC’，意思為‘通用元組編譯器’，但是這個名字并沒有出現(xiàn)在Visual Studio所包含的的任何二進(jìn)制文件里。后端先將信息從前端轉(zhuǎn)換為元組—–一個二進(jìn)制流的指令。顯示出來會看到它們看上去就像是一種高級匯編語言。感覺 上很高級：

1. 操作是通用的，例如，一個分支（LE）指令,以及它最終如何被翻譯成64位的機器碼CMP指令。
2. 操作數(shù)是象征性的，例如，一個由編譯器生成的臨時變量t66和一個運行時保存其值得64位寄存器eax。

因為我們要求編譯器優(yōu)化速度，通過/02開關(guān)，優(yōu)化部分后端，分析元組并將其轉(zhuǎn)化為另一種形式，使其運行得更快，但是語義上來講，卻是等價的，和原來的元組產(chǎn)生的同樣的結(jié)果。完成這步后，元組就會被傳給后端的CodeGen部分，最終會決定二進(jìn)制碼的產(chǎn)生。

CodeGen模塊會在磁盤上生成APP.obj文件，最后，鏈接器會利用該文件，并分析所有的引用庫，生成最終的二進(jìn)制文件App.exe。

在上面的圖表中，黑色箭頭顯示數(shù)據(jù)流（文本或者二進(jìn)制文件），紅色箭頭表示控制流。

（在該系列的后面文章里，當(dāng)我們涉及到整個程序的優(yōu)化，關(guān)于特定的/GL開關(guān)編譯器和/LTCG開關(guān)的鏈接器時，還會再回到這個圖表。 我們看到的是相同的框圖，但是卻以不同方式連接起來的。）

小結(jié)：

1. 前端需要理解C++源代碼，其他環(huán)節(jié)，像后端和鏈接器，大部分都是獨立于原始源語言的。他們工作在上面提到的元組上，形成一種更高層次的二進(jìn)制匯編語言。原始的源程序可以是任何的命令式語言，像FORTRAN或者Pascal。后端真的不會在意。

2. 后端的優(yōu)化部分會將元組轉(zhuǎn)換成運行更快的更有效的形式，這種轉(zhuǎn)換，我們稱之為優(yōu)化。(其實我們應(yīng)該稱之為’改進(jìn)’，因為還有其他的改進(jìn)，可以產(chǎn)生運行更快 的代碼——我們只是盡力接近理想狀態(tài)。 然而，幾十年前，有人創(chuàng)造了一個術(shù)語’優(yōu)化’，我們都深陷其中。) 還有很多這樣的優(yōu)化方法，像’常量合并’、’消除公共子表達(dá)式’、 ‘提升’、 ‘外提不變表達(dá)式’、‘冗余代碼消除’、’ 內(nèi)聯(lián)函數(shù)’、 ‘自動向量化’等等.。大多數(shù)情況下。這些優(yōu)化都是獨立于程序所運行的最終處理器—–他們都是獨立于機器的優(yōu)化。

3. 后端的CodeGen部分決定如何制定運行時堆棧(用于實現(xiàn)’激活框架’)；怎么樣充分利用可用的機器寄存器；添加函數(shù)調(diào)用約定的細(xì)節(jié)；使用目標(biāo)機器的詳細(xì)介紹來轉(zhuǎn)換代碼，讓它運行得更快。

(舉一個小例子，如果你看匯編代碼，例如，你在調(diào)試代碼的時候，同時使用Visual Studio(Alt+8)的反匯編窗口—- 你可能會注意到一些用于將EAX置為0的指令像 xor eax, eax ，優(yōu)于一些更直接的指令 move eax,0. 為什么呢？因為XOR 指令更小（只有2個字節(jié)），執(zhí)行速度更快。我們也稱它為“微優(yōu)化”，也許你會懷疑是否值得這么麻煩？還記得那句諺語嗎？積少才能成多。)

與優(yōu)化相比，CodeGen就必須很清楚代碼將要運行的處理器架構(gòu)。有些情況下，在理解目標(biāo)處理器的基礎(chǔ)上，它甚至?xí)淖儥C器指令的布局順序—–稱 之為‘調(diào)度’。我最好還是再解釋一下： CodeGen知道它是針對x86，x64還是ARM-32， 知道代碼將要運行的處理器的具體的微架構(gòu)還是很罕見的，以 Nehalem和Sandy Bridge為例（看看/favor:ATOM 這個案例，可以更多的詳情）

這篇文章重點講編譯器的優(yōu)化部分，很少提及構(gòu)成前端， CodeGen或者鏈接器的其他組件。

這篇文章介紹了大量的術(shù)語，我沒有打算讓你全部理解它們：畢竟這只是一篇概述，傳播一些思想，希望你會感興趣，確保讀完你下次還會再來，我會開始講解所有的術(shù)語。

下次，我們一起來看看最簡單的一種優(yōu)化方法和它的工作原理——–合并常量。

原文鏈接：http://blogs.msdn.com/b/vcblog/archive/2013/06/12/optimizing-c-code-new-title.aspx

譯文鏈接：http://blog.jobbole.com/47148/