編譯器架構(gòu)Compiler Architecture（下）

Combining Scanning and Parsing

實際上沒有必要將掃描（詞法分析/標(biāo)記化）與解析（語法分析/樹生成）分開?；赑EGs的系統(tǒng)，比如Ohm，實際上是無掃描的：它們以一種預(yù)測的方式執(zhí)行解析，將詞匯和語法規(guī)則混合在一起。（但是，像Ohm這樣的系統(tǒng)需要一個預(yù)解析階段來處理縮進(jìn)和凹陷。）
當(dāng)使用無掃描系統(tǒng)時，語言設(shè)計者和編譯器編寫者仍然會考慮符號和短語，但不必?fù)?dān)心像所謂的最大Munch原則這樣的復(fù)雜規(guī)則。Lookahead捕獲您需要的任何類型的標(biāo)記化方案。此外，無掃描解析的預(yù)測性意味著我們不必確定*是一元運(yùn)算符指針解引用令牌，還是二進(jìn)制乘法運(yùn)算符令牌或星形令牌。在進(jìn)行預(yù)測性分析時，我們總是有上下文。

Semantic Analysis

在語義分析過程中，我們必須檢查合法性規(guī)則，同時，我們將語法樹的片段（通過解析標(biāo)識符引用、為隱式強(qiáng)制插入強(qiáng)制轉(zhuǎn)換操作等）捆綁起來，形成一個語義圖。
繼續(xù)上面的例子：


顯然，每種語言的合法性規(guī)則是不同的。您可能會在類似Java的語言中看到的合法性規(guī)則示例包括：

一個范圍內(nèi)的變量的多個聲明

在變量聲明之前引用它

引用沒有聲明的標(biāo)識符

違反訪問（公共、私有、受保護(hù)等）規(guī)則

方法調(diào)用中的參數(shù)太多

方法調(diào)用中沒有足夠的參數(shù)

類型不匹配（有很多這樣的情況）

練習(xí)：列舉以上每一個例子。

在此階段發(fā)生的錯誤稱為靜態(tài)語義錯誤。

練習(xí)：Pascal語言在表達(dá)式方面有一種不同尋常的語法：它賦予and運(yùn)算符（需要布爾操作數(shù)）比關(guān)系運(yùn)算符更高的優(yōu)先級！說明這意味著表達(dá)式x-4<=5和2<y是靜態(tài)語義錯誤。

中間代碼生成Intermediate Code Generation

中間代碼生成器生成一個流圖，由分組到基本塊中的元組組成。對于上面的例子，我們可以看到：

可以在其他地方關(guān)于中間表示的內(nèi)容。

Machine Independent Code Improvement

對語義圖或中間代碼進(jìn)行的代碼改進(jìn)稱為與機(jī)器無關(guān)的代碼優(yōu)化。在實踐中，有無數(shù)已知的優(yōu)化（er，改進(jìn)），但沒有一個真正適用于我們的運(yùn)行示例。

Code Generation

代碼生成產(chǎn)生實際的目標(biāo)代碼，或者類似的代碼。這是我在使用面向x86-64的gcc 6.3進(jìn)行組裝時得到的結(jié)果，沒有任何優(yōu)化：

以下是ARM的代碼，使用gcc 5.4，無需優(yōu)化：

MIPS代碼，gcc 5.4也未優(yōu)化：

Machine Dependent Code Improvement

通常編譯的最后階段是清理和改進(jìn)目標(biāo)代碼。對于上面的例子，我在將優(yōu)化級別設(shè)置為-O3時得到了如下結(jié)論：

Optimized ARM code:

Optimized MIPS code:

總結(jié)

以上是生活随笔為你收集整理的编译器架构Compiler Architecture（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。