編譯器後端優化技巧

1. 編譯器生成的匯編語句執行順序為什麼與C代碼順序不同

不影響語義的前提下編譯器可以任意重排代碼順序；
在亂序執行（Out-of-Order）的CPU里，機器碼的執行也可以不按照你在「匯編」層面上看到的順序執行，只要不影響語義。
所以說這些中間步驟的順序，作為底層細節平時不需要那麼在意——它們多半跟原始源碼的順序是不一樣的。

現代優化編譯器優化的思路之一是「基於依賴的優化」（dependence-based optimization）。題主引用的CSAPP的例子：

int arith(int x, int y, int z) {
int t1 = x + y;
int t2 = z * 48;
int t3 = t1 & 0xFFFF;
int t4 = t2 * t3;
return t4;
}

所有涉及運算的值都是局部標量變數（local scalar variable），這是最便於編譯器做分析的情況，所有依賴都可以顯式分析。
由於整個函數沒有分支，這里也不需要討論控制依賴（control dependence），只要討論數據依賴（data dependence）就好。
把數據依賴圖畫出來是個DAG（這里正好是棵樹，特例了）：

x y z 48
\ / \ /
t1 0xFFFF t2
\ / /
t3 /
\ /
t4

優化必須要滿足的約束是：每個節點求值之前，其子節點（依賴的數據源）必須要先求了值。
顯然，t1和t2之間沒有依賴關系，它們的相對求值順序怎樣重排都沒關系。

有本我很喜歡的書，裡面講的是各種基於依賴的優化：Optimizing Compilers for Modern Architectures - A Dependence-based Approach

以上是理論部分。

================================================================

下面來看例子。

我們可以用一個實際編譯器來看看CSAPP的例子編譯出來的結果：

.text
# -- Begin arith
.p2align 4,,15
.globl arith
.type arith, @function
arith:
.p2align 4,,7
/*.L0:*/ /* Block BB[54:2] preds: none, freq: 1.000 */
movl 8(%esp), %edx /* ia32_Load T[139:10] -:1:22 */
addl 4(%esp), %edx /* ia32_Add Iu[141:12] -:2:14 */
movzwl %dx, %edx /* ia32_Conv_I2I Iu[142:13] -:4:15 */
imull 12(%esp), %edx /* ia32_IMul Iu[143:14] -:5:15 */
leal (%edx,%edx,2), %eax /* ia32_Lea Iu[144:15] -:5:15 */
shll $0x4, %eax /* ia32_Shl Iu[146:17] -:5:15 */
ret /* ia32_Return X[152:23] -:6:3 */
.size arith, .-arith
# -- End arith

這里用的是libFirm。可見它跟CSAPP書里所說的匯編的順序又有所不同。這也是完全合理的。
這個編譯結果的順序是：

edx = y;
edx += x;
edx = zeroextend dx; // edx = edx & 0xFFFF
edx *= z;
eax = edx * 3;
eax <<= 4; // eax = eax * 16

也是完全符合依賴關系的約束的一種順序。
之所以用libFirm舉例是因為它的中間表示（Intermediate Representation）是一種程序依賴圖（Program Dependence Graph），可以很方便的看出控制與數據依賴。把CSAPP那裡例子對應的libFirm IR畫出來，是這個樣子的：
（這張圖跟我前面畫的數據依賴圖正好是左右翻轉的，不過意思一樣。（這張圖跟我前面畫的數據依賴圖正好是左右翻轉的，不過意思一樣。
Arg 0、1、2分別代表x、y、z。白色方塊是普通數據節點，黃色方塊是常量節點，藍色方塊是內存相關節點，紅色方塊是控制流節點，粉紅色方塊是特殊的開始/結束節點。）

某版LLVM生成的代碼：

; MoleID = '/tmp/webcompile/_16355_0.bc'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-ellcc-linux"

; Function Attrs: nounwind readnone
define i32 @arith(i32 %x, i32 %y, i32 %z) #0 {
entry:
%add = add nsw i32 %y, %x
%mul = mul nsw i32 %z, 48
%and = and i32 %add, 65535
%mul1 = mul nsw i32 %mul, %and
ret i32 %mul1
}

attributes #0 = { nounwind readnone "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.ident = !{!0}

!0 = !{!"ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"}

最終生成的x86匯編：

.text
.file "/tmp/webcompile/_15964_0.c"
.globl arith
.align 16, 0x90
.type arith,@function
arith: # @arith
# BB#0: # %entry
movl 8(%esp), %eax
addl 4(%esp), %eax
movzwl %ax, %eax
imull 12(%esp), %eax
shll $4, %eax
leal (%eax,%eax,2), %eax
retl
.Ltmp0:
.size arith, .Ltmp0-arith

.ident "ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"
.section ".note.GNU-stack","",@progbits

GCC 4.9.2 x86-64：

arith(int, int, int):
leal (%rdx,%rdx,2), %eax
addl %edi, %esi
movzwl %si, %esi
sall $4, %eax
imull %esi, %eax
ret

Zing VM Server Compiler x86-64：

# edi: x
# esi: y
# edx: z
movl %edx, %eax
shll $0x4, %eax
leal (%rsi, %rdi, 1), %ecx
shll $0x5, %edx
addl %edx, $eax
movzwl %ecx, %edx
imull %edx, %eax

2. 通過編譯器對程序優化來改進cache性能的方法有哪幾種

你的程序可能太短，看不出區別來，你比對一下她們生成的匯編碼就知道了

CPU 緩存是為了提高程序運行的性能，CPU 在很多處理上內部架構做了很多調整，比如 CPU 高速緩存，大家都知道因為硬碟很慢，可以通過緩存把數據載入到內存裡面，提高訪問速度，而 CPU 處理也有這個機制，盡可能把處理器訪問主內存時間開銷放在 CPU 高速緩存上面，CPU 訪問速度相比內存訪問速度又要快好多倍，這就是目前大多數處理器都會去利用的機制，利用處理器的緩存以提高性能。

就算優化帶來的效果非常有限，但是經過長年累月的持續優化，效果也是非常明顯的，比如當年的Chrome瀏覽器就是靠打開網頁非常快從而打敗微軟系統自帶的IE瀏覽器。電腦手機等硬體的性能是有限的，不同的演算法會產生不同的效率，今天我們就簡單說一個選擇問題，開發程序時是節省內存還是節省計算量。

3. 什麼是編譯器

編譯器

編譯器是一種特殊的程序，它可以把以特定編程語言寫成的程序變為機器可以運行的機器碼。我們把一個程序寫好，這時我們利用的環境是文本編輯器。這時我程序把程序稱為源程序。在此以後程序員可以運行相應的編譯器，通過指定需要編譯的文件的名稱就可以把相應的源文件（通過一個復雜的過程）轉化為機器碼了。

[編輯]編譯器工作方法
首先編譯器進行語法分析，也就是要把那些字元串分離出來。然後進行語義分析，就是把各個由語法分析分析出的語法單元的意義搞清楚。最後生成的是目標文件，我們也稱為obj文件。再經過鏈接器的鏈接就可以生成最後的可執行代碼了。有些時候我們需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。我們把一過程稱為交叉鏈接。

一個現代編譯器的主要工作流程如下：

* 源程序（source code）→預處理器（preprocessor）→編譯器（compiler）→匯編程序（assembler）→目標程序（object code）→連接器（鏈接器，Linker）→可執行程序（executables）

工作原理

編譯是從源代碼（通常為高級語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低級語言或機器言）。然而，也存在從低級語言到高級語言的編譯器，這類編譯器中用來從由高級語言生成的低級語言代碼重新生成高級語言代碼的又被叫做反編譯器。也有從一種高級語言生成另一種高級語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。

典型的編譯器輸出是由包含入口點的名字和地址以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。

編譯器種類

編譯器可以生成用來在與編譯器本身所在的計算機和操作系統（平台）相同的環境下運行的目標代碼，這種編譯器又叫做「本地」編譯器。另外，編譯器也可以生成用來在其它平台上運行的目標代碼，這種編譯器又叫做交叉編譯器。交叉編譯器在生成新的硬體平台時非常有用。「源碼到源碼編譯器」是指用一種高級語言作為輸入，輸出也是高級語言的編譯器。例如: 自動並行化編譯器經常採用一種高級語言作為輸入，轉換其中的代碼，並用並行代碼注釋對它進行注釋（如OpenMP）或者用語言構造進行注釋（如FORTRAN的DOALL指令）。

預處理器（preprocessor）

作用是通過代入預定義等程序段將源程序補充完整。

編譯器前端（frontend）

前端主要負責解析（parse）輸入的源程序，由詞法分析器和語法分析器協同工作。詞法分析器負責把源程序中的『單詞』（Token）找出來,語法分析器把這些分散的單詞按預先定義好的語法組裝成有意義的表達式，語句 ，函數等等。 例如「a = b + c;」前端詞法分析器看到的是「a, =, b , +, c;」，語法分析器按定義的語法，先把他們組裝成表達式「b + c」，再組裝成「a = b + c」的語句。 前端還負責語義（semantic checking）的檢查，例如檢測參與運算的變數是否是同一類型的，簡單的錯誤處理。最終的結果常常是一個抽象的語法樹（abstract syntax tree，或 AST），這樣後端可以在此基礎上進一步優化，處理。

編譯器後端（backend）

編譯器後端主要負責分析，優化中間代碼（Intermediate representation）以及生成機器代碼（Code Generation）。

一般說來所有的編譯器分析，優化，變型都可以分成兩大類： 函數內（intraproceral）還是函數之間（interproceral）進行。很明顯，函數間的分析，優化更准確，但需要更長的時間來完成。

編譯器分析（compiler analysis）的對象是前端生成並傳遞過來的中間代碼，現代的優化型編譯器（optimizing compiler）常常用好幾種層次的中間代碼來表示程序，高層的中間代碼（high level IR）接近輸入的源程序的格式，與輸入語言相關（language dependent），包含更多的全局性的信息，和源程序的結構；中層的中間代碼（middle level IR）與輸入語言無關，低層的中間代碼(Low level IR)與機器語言類似。 不同的分析，優化發生在最適合的那一層中間代碼上。

常見的編譯分析有函數調用樹（call tree），控制流程圖（Control flow graph），以及在此基礎上的變數定義－使用，使用－定義鏈（define-use/use-define or u-d/d-u chain），變數別名分析（alias analysis），指針分析（pointer analysis），數據依賴分析（data dependence analysis）等等。

上述的程序分析結果是編譯器優化（compiler optimization）和程序變形（compiler transformation）的前提條件。常見的優化和變新有：函數內嵌（inlining），無用代碼刪除（Dead code elimination），標准化循環結構（loop normalization），循環體展開（loop unrolling），循環體合並，分裂（loop fusion，loop fission），數組填充（array padding），等等。優化和變形的目的是減少代碼的長度，提高內存（memory），緩存（cache）的使用率，減少讀寫磁碟，訪問網路數據的頻率。更高級的優化甚至可以把序列化的代碼（serial code）變成並行運算，多線程的代碼（parallelized，multi-threaded code）。

機器代碼的生成是優化變型後的中間代碼轉換成機器指令的過程。現代編譯器主要採用生成匯編代碼（assembly code）的策略，而不直接生成二進制的目標代碼（binary object code）。即使在代碼生成階段，高級編譯器仍然要做很多分析，優化，變形的工作。例如如何分配寄存器（register allocatioin），如何選擇合適的機器指令（instruction selection），如何合並幾句代碼成一句等等。

4. 學C語言現在最好用的編程軟體

GNU編譯器套裝
開發 The GNU Project
最新版本 4.4.2 / 2009-10-15（2個月前）
操作系統 跨平台
類型 編譯器
許可協議 GPL
網站 gcc.gnu.org

GCC（GNU Compiler Collection，GNU編譯器套裝），是一套由GNU開發的編程語言編譯器。它是一套以GPL及LGPL許可證所發行的自由軟體，也是GNU計劃的關鍵部分，亦是自由的類Unix及蘋果計算機Mac OS X 操作系統的標准編譯器。GCC（特別是其中的C語言編譯器）也常被認為是跨平台編譯器的事實標准。

GCC原名為GNU C語言編譯器（GNU C Compiler），因為它原本只能處理C語言。GCC很快地擴展，變得可處理C++。之後也變得可處理Fortran、Pascal、Objective-C、Java，以及Ada與其他語言。
目錄
[隱藏]

* 1 概觀
* 2 目前支持的語言
o 2.1 內嵌OpenMP支持
* 3 支持的處理器架構
* 4 結構
o 4.1 前端介面
o 4.2 中介介面
o 4.3 後端介面
* 5 替GCC程序除錯
* 6 參考書目及注釋
* 7 參閱
* 8 更多閱讀
* 9 外部鏈接

[編輯] 概觀

GCC是由理查德·馬修·斯托曼在1985年開始的。他首先擴增一個舊有的編譯器，使它能編譯C，這個編譯器一開始是以Pastel語言所寫的。Pastel是一個不可移植的Pascal語言特殊版，這個編譯器也只能編譯Pastel語言。為了讓自由軟體有一個編譯器，後來此編譯器由斯托曼和Len Tower在1987年[1]以C語言重寫[2]並成為GNU項目的編譯器。GCC的建立者由自由軟體基金會直接管理[3]。

在1997年，一群不滿GCC緩慢且封閉的創作環境者，組織了一個名為EGCS《Experimental/Enhanced GNU Compiler System》的項目，此項目匯整了數項實驗性的分支進入某個GCC項目的分支中。EGCS比起GCC的建構環境更有活力，且EGCS最終也在1999年四月成為GCC的官方版本。

GCC目前由世界各地不同的數個程序設計師小組維護。它是移植到中央處理器架構以及操作系統最多的編譯器。

由於GCC已成為GNU系統的官方編譯器（包括GNU/Linux家族），它也成為編譯與建立其他操作系統的主要編譯器，包括BSD家族、Mac OS X、NeXTSTEP與BeOS。

GCC通常是跨平台軟體的編譯器首選。有別於一般局限於特定系統與運行環境的編譯器，GCC在所有平台上都使用同一個前端處理程序，產生一樣的中介碼，因此此中介碼在各個其他平台上使用GCC編譯，有很大的機會可得到正確無誤的輸出程序。
[編輯] 目前支持的語言

以2006年5月24日釋出的4.1.1版為准，本編譯器版本可處理下列語言：

* Ada 《GNAT》
* C 《GCC》
* C++（G++）
* Fortran 《Fortran 77: G77，Fortran 90: GFORTRAN》

* Java 《編譯器：GCJ；解釋器：GIJ》
* Objective-C 《GOBJC》
* Objective-C++

先前版本納入的CHILL前端由於缺乏維護而被廢棄。

Fortran前端在4.0版之前是G77，此前端僅支持Fortran 77。在本版本中，G77被廢棄而採用更新的GFortran，因為此前端支持Fortran 95。

下列前端依然存在：

* Mola-2
* Mola-3
* Pascal
* PL/I

* D語言
* Mercury
* VHDL

[編輯] 內嵌OpenMP支持

OpenMP是一種跨語言的對稱多處理器（SMP）多線程並行程序的編程工具，也非常適合當今越來越流行的單CPU多核硬體環境，因此從gcc4.2開始，OpenMP成為其內嵌支持的並行編程規范，可以直接編譯內嵌 OpenMP語句的C/C++/Fortran95的源代碼。gcc4.2之前如果想在C/C++/Fortran中嵌入OpenMP語句的話，需要額外安裝庫和預處理器才能識別和正確處理這些語句。

* gcc 4.2.0開始支持OpenMP v2.5
* gcc 4.4.0開始支持OpenMP v2.5及v3.0

參見GNU的GOMP計劃
[編輯] 支持的處理器架構

GCC目前支持下列處理器架構（以4.1版為准）：

* Alpha
* ARM
* Atmel AVR
* Blackfin
* H8/300
* IA-32（x86）與x86-64
* IA-64例如：Itanium

* MorphoSys家族
* Motorola 68000
* Motorola 88000
* MIPS
* PA-RISC
* PDP-11
* PowerPC

* System/370，System/390
* SuperH
* HC12
* SPARC
* VAX
* Renesas R8C／M16C／M32C家族

較不知名的處理器架構也在官方釋出版本中支持：

* A29K
* ARC
* C4x
* CRIS
* D30V
* DSP16xx
* FR-30
* FR-V

* Intel i960
* IP2000
* M32R
* 68HC11
* MCORE
* MMIX

* MN10200
* MN10300
* NS32K
* ROMP
* Stormy16
* V850
* Xtensa

由FSF個別維護的GCC處理器架構：

* D10V
* MicroBlaze

* PDP-10
* MSP430

* Z8000

當GCC需要移植到一個新平台上，通常使用此平台固有的語言來撰寫其初始階段。
[編輯] 結構

GCC的外部介面長得像一個標準的Unix編譯器。用戶在命令行下鍵入gcc之程序名，以及一些命令參數，以便決定每個輸入文件使用的個別語言編譯器，並為輸出代碼使用適合此硬體平台的匯編語言編譯器，並且選擇性地運行連接器以製造可運行的程序。

每個語言編譯器都是獨立程序，此程序可處理輸入的源代碼，並輸出匯編語言碼。全部的語言編譯器都擁有共通的中介架構：一個前端解析符合此語言的源代碼，並產生一抽象語法樹，以及一翻譯此語法樹成為GCC的寄存器轉換語言《RTL》的後端。編譯器優化與靜態代碼解析技術（例如FORTIFY_SOURCE[1]，一個試圖發現緩存溢出《buffer overflow》的編譯器）在此階段應用於代碼上。最後，適用於此硬體架構的匯編語言代碼以Jack Davidson與Chris Fraser發明的演算法產出。

幾乎全部的GCC都由C寫成，除了Ada前端大部分以Ada寫成。
[編輯] 前端介面

前端的功能在於產生一個可讓後端處理之語法樹。此語法解析器是手寫之遞回語法解析器。

直到最近，程序的語法樹結構尚無法與欲產出的處理器架構脫鉤。而語法樹的規則有時在不同的語言前端也不一樣，有些前端會提供它們特別的語法樹規則。

在2005年，兩種與語言脫鉤的新型態語法樹納入GCC中。它們稱為GENERIC與GIMPLE。語法解析變成產生與語言相關的暫時語法樹，再將它們轉成GENERIC。之後再使用"gimplifier"技術降低GENERIC的復雜結構，成為一較簡單的靜態唯一形式（Static Single Assignment form，SSA）基礎的GIMPLE形式。此形式是一個與語言和處理器架構脫鉤的全局優化通用語言，適用於大多數的現代編程語言。
[編輯] 中介介面

一般編譯器作者會將語法樹的優化放在前端，但其實此步驟並不看語言的種類而有不同，且不需要用到語法解析器。因此GCC作者們將此步驟歸入通稱為中介階段的部分里。此類的優化包括消解死碼、消解重復計算與全局數值重編碼等。許多優化技巧也正在實現中。
[編輯] 後端介面

GCC後端的行為因不同的前處理器宏和特定架構的功能而不同，例如不同的字元尺寸、調用方式與大小尾序等。後端介面的前半部利用這些消息決定其RTL的生成形式，因此雖然GCC的RTL理論上不受處理器影響，但在此階段其抽象指令已被轉換成目標架構的格式。

GCC的優化技巧依其釋出版本而有很大不同，但都包含了標準的優化演算法，例如循環優化、線程跳躍、共通程序子句消減、指令調度等等。而RTL的優化由於可用的情形較少，且缺乏較高級的信息，因此比較起近來增加的GIMPLE語法樹形式[2]，便顯得比較不重要。

後端經由一重讀取步驟後，利用描述目標處理器的指令集時所取得的信息，將抽象寄存器替換成處理器的真實寄存器。此階段非常復雜，因為它必須關照所有GCC可移植平台的處理器指令集的規格與技術細節。

後端的最後步驟相當公式化，僅僅將前一階段得到的匯編語言碼藉由簡單的副函數轉換其寄存器與存儲器位置成相對應的機器碼。
[編輯] 替GCC程序除錯

為GCC除錯的首選工具當然是GNU除錯器。其他特殊用途的除錯工具是Valgrind，用以發現存儲器泄漏 (Memory leak)。而GNU測量器（gprof）可以得知程序中某些函數花費多少時間，以及其調用頻率；此功能需要用戶在編譯時選定測量《profiling》選項。
[編輯] 參考書目及注釋

* Richard M. Stallman：Using and Porting the GNU Compiler Collection, Free Software Foundation，ISBN 0-595-10035-X
* Richard M. Stallman: Using Gcc: The Gnu Compiler Collection Reference, Free Software Foundation, ISBN 1-882114-39-6
* Brian J. Gough：An Introction to GCC, Network Theory Ltd., ISBN 0-9541617-9-3

1. ^ Tower, Leonard (1987) "GNU C編譯器beta測試版釋出" comp.lang.misc USENET新聞組；參閱http://gcc.gnu.org/releases.html#timeline
2. ^ Stallman, Richard M.（1986年2月1日）．GNU狀態．GNU的公告版，1（1）．自由軟體基金會．
3. ^ Stallman, Richard M. (2001) "GCC貢獻者名單"於使用及移植GCC 2.95版（Cambridge, Mass.: Free Software Foundation）

[編輯] 參閱
[[File:|36x32px|自由軟體主題]] 自由軟體主題首頁

GCC目前包含了Boehm GC，一個為C/C++ 所設計的垃圾回收器。

* distcc - 為分布式編譯所設計的軟體，以GCC為協同軟體。
* LLVM - 低層虛擬機編譯器架構。
* MinGW - 將GNU開發工具移植到Win32平台下的計劃
* Cygwin - 在Windows上運行GNU程序的模擬軟體。
* GCC Summit
* OpenWatcom - 另一個開放原碼的C++/Fortran編譯器。
* Code Sourcery - 一個GCC顧問公司。
* ggcc - 全球化GCC項目。

[編輯] 更多閱讀

* Arthur Griffith, GCC: The Complete Reference. McGrawHill/Osborne. ISBN 0-07-222405-3.
* Kerner, Sean Michael．Open Source GCC 4.0: Older, Faster，internetnews.com，2005年4月22日．
* Kerner, Sean Michael．New GCC Heavy on Optimization，internetnews.com，2006年3月2日．

[編輯] 外部鏈接

* GCC官方網站
* GCC Forum - 由Nabble維持，整理所有gcc通信討論串，並集成入一個可搜索介面中。

5. c語言防止優化

編譯器編譯命令里有設置選項，通過設置，你可以要求 不優化，也可以要求用哪種優化。
具體選項有哪些，要查自己編譯器的幫助文件。
例如，MS VC++ 6.0 編譯器編
優化選項：
/O1：優化使產生的可執行代碼最小
/O2：優化使產生的可執行代碼速度最快
/Oa：指示編譯器程序里沒有使用別名，可以提高程序的執行速度
/Ob：控制內聯（inline）函數的展開
/Od：禁止代碼優化
/Og：使用全局優化
/Oi：用內部函數去代替程序里的函數調用，可以使程序運行的更快，但程序的長度變長
/Op：提高浮點數比較運算的一致性
/Os：產生盡可能小的可執行代碼
/Ot：產生盡可能塊的可執行代碼
/Ow：指示編譯器在函數體內部沒有使用別名
/Ox：組合了幾個優化開關，達到盡可能多的優化
/Oy：阻止調用堆棧里創建幀指針

/O2 為了加速，會優化掉。 選 /Od 不優化。

6. 編譯前端和後端各有什麼特點,各自包含編譯過程的哪幾個部分

編譯前端主要包括詞法分析、語法分析、語義分析、中間代碼生成這幾個部分，後端則包含代碼優化和目標代碼生成部分。前端的特點是僅與編譯的源語言有關，而後端則僅與編譯的目標語言及運行環境有關。

將編譯過程劃分成前端和後端，主要目的是在多種源語言和多種目標語言的開發過程中，可以靈活搭配組合，消除重復開發的工作量，提高編譯系統的開發效率。

7. 本科獨立用C語言完成沒有優化的C語言編譯器屬於什麼水平

我覺得水平還是很高的，但意義恐怕不大。編譯器技術是非常成熟的領域，而且由於應用場景的限
制實時，復雜的演算法已經自動出局了，你可選的東西是有限的。編譯器可能有很多實現的形
式，虛擬機/解釋器/靜態編譯器 等，也有成熟的開源實現。作為本科生，而非專門研究該分支的學生，應該合理分配自己學習的時間，如果做這個編譯器就干
掉了大半年，那計網和OS這些課程該咋辦？ 

我知道很多人會認為沒有做編譯器優化特指中段優化，不考慮機器碼上的優化比較劃水。但編
譯器優化是一個很復雜的東西：首先它和你用的IR表示有關而且是強烈耦合，SSA IR基本還
好，有開源代碼和文獻記載，你想要的都能在網上挖到但這怎麼體現你的水平是吧。你
要考慮編譯器的性能，盡管編譯器的後端優化基本上可以納入到某種PEabstract interpretation的
范疇中。

要不然你可以通過編寫插件的方式白嫖例如visual studio code這類軟
件的強大編輯功能,如果你寫的不是c compiler,你也可以盡量把語法設計得很像c,這樣你又能進一步
白嫖其強大的intellisense code,當然仍然有不少人或者應該說團隊達到了這一步,到這里,應該卷死
了99.99%的同行應該毫無問題。