簡介面向編譯原理課程學(xué)習(xí)者的完整課內(nèi)實(shí)驗(yàn)與課程設(shè)計(jì)資料由廣東工業(yè)大學(xué)學(xué)生在學(xué)習(xí)過程中整理系統(tǒng)覆蓋詞法分析、語法分析、語義分析及代碼生成四大編譯器核心階段并以PL0教學(xué)語言為實(shí)例串起整個(gè)實(shí)驗(yàn)環(huán)節(jié)適合本科階段復(fù)習(xí)、課程設(shè)計(jì)參考或自學(xué)實(shí)踐。資源共131個(gè)文件主要包含PL0源程序、C與Java工程源碼、編譯生成的class/exe產(chǎn)物、分析過程png截圖以及實(shí)驗(yàn)報(bào)告md筆記整體僅3.01MB目錄結(jié)構(gòu)清晰便于按需查找。目前已有500人學(xué)習(xí)下載。實(shí)驗(yàn)報(bào)告中詳細(xì)記錄了每一步實(shí)現(xiàn)細(xì)節(jié)、遇到的問題與解決思路配合源碼和可視化圖表可讓學(xué)習(xí)者直觀理解編譯器構(gòu)造流程掌握PL0解釋器或編譯器的搭建方法是完成課程實(shí)驗(yàn)、撰寫課程設(shè)計(jì)報(bào)告或進(jìn)行相關(guān)復(fù)習(xí)的高價(jià)值參考資料。1. 編譯原理課設(shè)就該拿 PL0 開刀這份 GDUT 實(shí)驗(yàn)包到底裝了什么編譯原理這門課最勸退的不是文法而是你永遠(yuǎn)不知道自己的編譯器離“能跑”還有多遠(yuǎn)。PL0 是 Pascal 之父 Wirth 設(shè)計(jì)的教學(xué)語言去掉一切工程復(fù)雜度幾十行 EBNF 文法就能描述全貌卻把詞法分析、語法分析、語義分析、代碼生成、解釋執(zhí)行這條編譯器流水線完整走了一遍。廣東工業(yè)大學(xué)GDUT這套課內(nèi)實(shí)驗(yàn)和課程設(shè)計(jì)資源正是拿一個(gè)可運(yùn)行的 PL0 編譯器當(dāng)載體把整個(gè)編譯流程拆成能動(dòng)手、能驗(yàn)收、能寫進(jìn)報(bào)告的分階段任務(wù)。對(duì)正在趕編譯原理實(shí)驗(yàn)的在校生來說它是現(xiàn)成的實(shí)現(xiàn)參照對(duì)自學(xué)編譯器構(gòu)造的開發(fā)者來說它是能真正跑起來的最小完整范例。最值錢的不只是代碼而是報(bào)告里記錄的那套“從設(shè)計(jì)到排錯(cuò)”的全過程。2. 先看清家底從 PL0.bpr 到 7 個(gè) class讀文件清單就是讀架構(gòu)2.1 PL0.bpr 重復(fù)出現(xiàn)Borland 工程文件背后的多實(shí)現(xiàn)版本PL0.bpr 是 Borland C Builder 的工程文件壓縮包里出現(xiàn)三次對(duì)應(yīng)三個(gè)不同實(shí)驗(yàn)階段的工程快照。也就是說這份資源不是孤零零的一份源碼而是一組按實(shí)驗(yàn)進(jìn)度不斷迭代的版本。結(jié)合 answer.cpp 的存在可以推斷第一個(gè)實(shí)驗(yàn)用 C 完成了詞法分析器的答案實(shí)現(xiàn)而 Parser.class、Scanner.class、Interpreter.class 這組 Java 編譯產(chǎn)物又在告訴你課程設(shè)計(jì)的最終形態(tài)大概率是用 Java 重寫了一遍完整編譯器。做課設(shè)時(shí)最怕的就是拿到手不知道從哪看起。我的習(xí)慣是先列文件清單再到每個(gè)文件里看它干了什么。這一步能幫你快速判斷這套資源的實(shí)現(xiàn)路線C 版本適合拿來對(duì)照詞法分析的原理Java 版本適合拿來跑通全流程實(shí)驗(yàn)報(bào)告負(fù)責(zé)把兩套代碼串成一條完整的故事線。2.2 七個(gè)核心 class 的職責(zé)邊界一句話說清每個(gè)類管什么PL0.class、Scanner.class、Parser.class、Interpreter.class、Table.class、Symbol.class、Fct.class這七個(gè)類的命名非常規(guī)整基本就是經(jīng)典編譯器教科書的分層結(jié)構(gòu)。我整理了一下class 文件職責(zé)對(duì)應(yīng)編譯階段Scanner.class詞法分析把字符流切成 token 流詞法分析Parser.class語法分析按文法規(guī)約 token同時(shí)驅(qū)動(dòng)語義動(dòng)作語法分析Table.class符號(hào)表管理常量、變量、過程定義語義分析Symbol.class單個(gè)符號(hào)項(xiàng)記錄名字、類型、地址語義分析Fct.class指令類型枚舉對(duì)應(yīng) P-code 中間指令代碼生成Interpreter.class按指令碼逐條執(zhí)行的解釋器目標(biāo)執(zhí)行PL0.class主入口讀取源文件并串聯(lián)各階段驅(qū)動(dòng)注意 Fct.class 的存在幾乎可以斷定它采用了經(jīng)典 PL0 的 P-code 指令集也就是 LIT、LOD、STO、CAL、INT、JMP、JPC、OPR 這一套棧式指令。這套設(shè)計(jì)幾十年來一直被編譯原理教材沿用因?yàn)樗闹噶詈唵蔚接檬止ぞ湍芙忉寛?zhí)行但又足夠覆蓋變量、表達(dá)式、條件跳轉(zhuǎn)、過程調(diào)用這些核心語言特性。想驗(yàn)證我的判斷不必去看源碼直接反編譯 class 文件就行。JDK 自帶的 javap 就是干這個(gè)的javap -c -p Parser.class | head -60這個(gè)命令的作用是反匯編 Parser.class輸出每個(gè)方法的字節(jié)碼指令。-c表示輸出方法體里的字節(jié)碼-p表示包含私有成員head -60只截取前 60 行避免刷屏。跑完之后你會(huì)看到 Parser 內(nèi)部持有 Scanner 實(shí)例的字段引用以及調(diào)用 Table 和 Fct 的操作碼這就等于把整個(gè)編譯器的主干關(guān)系摸了一遍。2.3 可視化文件和實(shí)驗(yàn)報(bào)告答辯時(shí)最值錢的素材CBC00.png、CBC.png、qt00.png 這三個(gè)圖片文件是詞法分析和語法分析過程的可視化輸出一般是用圖形方式展示 token 識(shí)別結(jié)果或者語法樹的構(gòu)造過程。這類截圖在實(shí)驗(yàn)報(bào)告里的分量比代碼本身還重——老師看報(bào)告時(shí)第一眼掃的就是你有沒有真正跑出結(jié)果圖比代碼直觀得多。PL0_Exp、PL0_Des、PL0_Raw 這三個(gè)文件從命名上看分別是 PL0 的表達(dá)式處理、聲明處理和原始語法定義。它們對(duì)應(yīng)了課程設(shè)計(jì)里“語義分析”這一塊的工作內(nèi)容。README.md 則是整份實(shí)驗(yàn)報(bào)告的外殼不只是說明文檔里面有每一步的實(shí)現(xiàn)細(xì)節(jié)、遇到的問題和解決方式這份“踩坑實(shí)錄”才是整套資源里最值得先讀的東西。3. 詞法分析實(shí)驗(yàn)復(fù)現(xiàn)把源程序字符流切成 token核心代碼與驗(yàn)收方法3.1 詞法分析器該輸出什么PL0 的五類 token 與處理邊界詞法分析器的輸入是一串字符輸出是一串 tokenPL0 的 token 分五類關(guān)鍵字、標(biāo)識(shí)符、無符號(hào)整數(shù)、運(yùn)算符和界符。關(guān)鍵字包括 BEGIN、END、IF、THEN、WHILE、DO、CONST、VAR、CALL、PROCEDURE、READ、WRITE、ODD 這些保留字運(yùn)算符包括 - * / # : ( ) , ; .其中#在 PL0 里表示“不等于”。這里有兩個(gè)容易踩的邊界第一標(biāo)識(shí)符必須以字母開頭后面可以跟字母或數(shù)字但如果出現(xiàn)1abc這種數(shù)字后直接接字母的寫法必須在詞法階段報(bào)錯(cuò)不能把1和abc拆成兩個(gè) token 放過去第二:、、這類雙字符運(yùn)算符必須做“最大匹配”也就是一次識(shí)別兩個(gè)字符不能把拆成和否則語法分析階段會(huì)徹底亂套。3.2 用 C 實(shí)現(xiàn)一個(gè)精簡 Scanner直接可編譯的核心代碼answer.cpp 是這份資源里詞法分析的 C 實(shí)現(xiàn)參考我按 PL0 標(biāo)準(zhǔn)寫了一版同樣思路的精簡 Scanner可以直接編譯運(yùn)行// pl0_scanner.cpp —— PL0 詞法分析器精簡實(shí)現(xiàn) // 編譯: g pl0_scanner.cpp -o pl0_scanner #include cctype #include cstring #include string #include iostream // 關(guān)鍵字表詞法分析器必須先把保留字和普通標(biāo)識(shí)符區(qū)分開 const char *keywords[] { BEGIN, END, IF, THEN, WHILE, DO, CONST, VAR, CALL, PROCEDURE, READ, WRITE, ODD }; // 判斷標(biāo)識(shí)符是否為關(guān)鍵字直接查表 bool isKeyword(const std::string word) { for (size_t i 0; i sizeof(keywords) / sizeof(keywords[0]); i) { if (word keywords[i]) return true; } return false; } // 從 src 的 pos 位置開始切一個(gè) tokenpos 是引用參數(shù)會(huì)持續(xù)推進(jìn) std::string nextToken(const std::string src, size_t pos) { // 跳過空白和換行PL0 標(biāo)準(zhǔn)語法沒有注釋符號(hào) while (pos src.size() isspace(src[pos])) pos; if (pos src.size()) return ; // 返回空串表示 EOF // 標(biāo)識(shí)符或關(guān)鍵字以字母開頭后續(xù)允許字母、數(shù)字、下劃線 if (isalpha(src[pos])) { size_t start pos; while (pos src.size() (isalnum(src[pos]) || src[pos] _)) pos; std::string word src.substr(start, pos - start); return isKeyword(word) ? word : IDENT( word ); } // 無符號(hào)整數(shù)連續(xù)數(shù)字PL0 只支持整數(shù)不支持浮點(diǎn) if (isdigit(src[pos])) { size_t start pos; while (pos src.size() isdigit(src[pos])) pos; return NUMBER( src.substr(start, pos - start) ); } // 雙字符運(yùn)算符必須放在單字符判斷之前否則 會(huì)被拆開 if (pos 1 src.size() src[pos] : src[pos 1] ) { pos 2; return :; } if (pos 1 src.size() src[pos] src[pos 1] ) { pos 2; return ; } if (pos 1 src.size() src[pos] src[pos 1] ) { pos 2; return ; } // 單字符運(yùn)算符和界符直接返回當(dāng)前字符 return std::string(1, src[pos]); } int main() { std::string src VAR x, y; BEGIN x : y 2 END.; size_t pos 0, cnt 0; while (true) { std::string tok nextToken(src, pos); if (tok.empty()) break; std::cout cnt : tok \n; } return 0; }代碼里的關(guān)鍵邏輯是這三處isalpha(src[pos])判斷標(biāo)識(shí)符起始條件因?yàn)?PL0 規(guī)定標(biāo)識(shí)符必須以字母開頭不能用下劃線開頭連續(xù)數(shù)字用isdigit逐字符拼出整數(shù)但沒有做溢出檢查實(shí)驗(yàn)里一般不管這個(gè)雙字符運(yùn)算符判斷必須在單字符之前這是最大匹配原則的直接應(yīng)用。如果調(diào)換順序:會(huì)被拆成:和兩個(gè) token后續(xù)語法分析全都白做。3.3 運(yùn)行驗(yàn)證與邊界用例怎么確認(rèn) token 序列不漏不重寫完 Scanner 別急著往下走先把驗(yàn)收用例設(shè)計(jì)好。我一般會(huì)準(zhǔn)備幾組邊界輸入VAR x, y; BEGIN x : y 2 END.這是標(biāo)準(zhǔn)程序期望輸出依次是VAR、IDENT(x)、,、IDENT(y)、;、BEGIN、IDENT(x)、:、IDENT(y)、、NUMBER(2)、END、.一共 13 個(gè) token。如果輸出里多出或漏掉一個(gè)說明某個(gè)分支的pos推進(jìn)有問題這是詞法實(shí)驗(yàn)最常見的錯(cuò)誤來源。再測(cè)兩組特殊情況IF x y THEN x : 1用來驗(yàn)證沒有被拆開VAR 1x;用來驗(yàn)證數(shù)字后直接接標(biāo)識(shí)符的情況。對(duì)第二種上面這版代碼會(huì)把1輸出成 NUMBER把x輸出成 IDENT這在標(biāo)準(zhǔn) PL0 里是詞法錯(cuò)誤理想情況應(yīng)當(dāng)在isdigit分支里追加檢查讀完數(shù)字后若當(dāng)前字符是字母直接報(bào)告非法 token 并中止。這一步建議你自己加上因?yàn)樗抢蠋熥類劭鄯值男〖?xì)節(jié)。4. 語法與語義分析從 token 流到中間指令再到解釋執(zhí)行4.1 PL0 的 EBNF 文法與遞歸下降設(shè)計(jì)的映射關(guān)系詞法分析只負(fù)責(zé)切 token真正的“讀懂程序結(jié)構(gòu)”是語法分析的事。PL0 的完整文法用 EBNF 寫出來也就十幾行program block . . block [ CONST ident number {, ident number} ] [ VAR ident {, ident} ] { PROCEDURE ident ; block ; } statement . statement ident : expression | CALL ident | BEGIN statement {; statement} END | IF condition THEN statement | WHILE condition DO statement | READ ident | WRITE expression . condition ODD expression | expression (|#||||) expression . expression [|-] term {(|-) term} . term factor {(*|/) factor} . factor ident | number | ( expression ) .遞歸下降分析的做法就是給每個(gè)非終結(jié)符寫一個(gè)同名函數(shù)函數(shù)體里按產(chǎn)生式右側(cè)的順序逐項(xiàng)消費(fèi) token。這個(gè)方案相比自底向上的 LR 分析代碼量小得多而且出錯(cuò)時(shí)可以直接打印出“在第幾行缺了什么”這是教學(xué)編譯器幾乎都選遞歸下降的根本原因。你在這份資源的 Parser.class 里反編譯看到的就是一組按 expression、term、factor 嵌套設(shè)計(jì)的函數(shù)。4.2 符號(hào)表與指令集設(shè)計(jì)Table/Symbol/Fct 三件套分工語義分析階段要處理兩件事一是檢查變量有沒有聲明、類型對(duì)不對(duì)二是為代碼生成準(zhǔn)備地址信息。這份資源里的 Table.class 負(fù)責(zé)維護(hù)符號(hào)表Symbol.class 定義單個(gè)符號(hào)項(xiàng)Fct.class 枚舉中間指令。經(jīng)典的 PL0 符號(hào)表是每層過程一張表通過層差level和地址addr來定位變量。下面是一個(gè)簡化但結(jié)構(gòu)完整的 Java 實(shí)現(xiàn)// Symbol.java —— 符號(hào)項(xiàng)定義 public class Symbol { String name; // 符號(hào)名 int kind; // 0常量, 1變量, 2過程 int level; // 所在過程層差 int addr; // 在本層符號(hào)表中的位置 int value; // 常量值變量和過程不用 public Symbol(String name, int kind, int level, int addr, int value) { this.name name; this.kind kind; this.level level; this.addr addr; this.value value; } }// Table.java —— 單層符號(hào)表負(fù)責(zé)登記和查找 import java.util.LinkedHashMap; import java.util.Map; public class Table { private MapString, Symbol symbols new LinkedHashMap(); private int nextAddr; // 下一個(gè)可分配的符號(hào)表地址槽 // 向表中登記一個(gè)符號(hào)重復(fù)定義返回 -1 public int enter(String name, int kind, int level, int value) { if (symbols.containsKey(name)) { System.err.println(錯(cuò)誤符號(hào) name 重復(fù)定義); return -1; } Symbol s new Symbol(name, kind, level, nextAddr, value); symbols.put(name, s); return s.addr; } // 在當(dāng)前層查找符號(hào) public Symbol find(String name) { return symbols.get(name); } }這段代碼里的LinkedHashMap保證符號(hào)按聲明順序排列方便生成報(bào)告時(shí)展示符號(hào)表內(nèi)容。enter返回的是地址槽位語法分析拿到這個(gè)地址后會(huì)交給代碼生成階段寫入 P-code。4.3 P-code 指令集與 Interpreter 的執(zhí)行模型PL0 的中間代碼不用三元式也不用四元式而是一套基于棧的 P-code 指令。每條指令三個(gè)字段指令碼、層差、操作數(shù)。核心指令就這幾條指令含義作用LIT 0, 常量加載常量把常量壓入棧頂LOD 層差, 地址加載變量按層差和地址取變量值壓棧STO 層差, 地址存儲(chǔ)變量把棧頂值寫入變量地址INT 0, 大小分配空間為局部變量在棧上開辟空間JMP 0, 地址無條件跳轉(zhuǎn)讓程序計(jì)數(shù)器跳到目標(biāo)位置JPC 0, 地址條件跳轉(zhuǎn)棧頂為假時(shí)跳轉(zhuǎn)CAL 層差, 地址調(diào)用過程保存返回地址并跳轉(zhuǎn)OPR 0, 運(yùn)算號(hào)運(yùn)行運(yùn)算彈出棧頂元素做加減乘除或比較Interpreter 的核心就是個(gè) while 循環(huán)加 switch逐條讀指令、逐條執(zhí)行。這里給一版 Java 簡化實(shí)現(xiàn)// InterpreterLoop.java —— P-code 解釋執(zhí)行主循環(huán)結(jié)構(gòu)簡化版 public class InterpreterLoop { // 棧式虛擬機(jī)stack[top] 是棧頂top 從 0 開始遞增 private int[] stack new int[1000]; private int top 0; // code 數(shù)組模擬代碼區(qū)每行是 {指令碼, 層差, 操作數(shù)} public void execute(int[][] code) { int pc 0; while (pc code.length) { int fct code[pc][0]; int level code[pc][1]; int addr code[pc][2]; pc; // 先取指令再自增防止跳轉(zhuǎn)指令覆蓋當(dāng)前指令 switch (fct) { case 0: // LIT stack[top] addr; break; case 1: // LOD // 這里用 base(level) 找層差對(duì)應(yīng)的棧基地址 stack[top] stack[base(level) addr]; break; case 2: // STO stack[base(level) addr] stack[--top]; break; case 5: // JMP pc addr; break; case 6: // JPC if (stack[--top] 0) pc addr; break; case 9: // OPR 的簡化入口運(yùn)算號(hào)在 addr 里 runOp(addr); break; } } } private int base(int level) { // 完整版需要維護(hù) display 寄存器數(shù)組這里返回 0 只是占位 return 0; } private void runOp(int op) { // 按 op 區(qū)分 - * / 比較等運(yùn)算具體指令分配見實(shí)驗(yàn)報(bào)告 } }這里的base(level)是最關(guān)鍵也最容易寫錯(cuò)的地方。真實(shí) PL0 在棧上維護(hù)了靜態(tài)鏈SL和動(dòng)態(tài)鏈DLbase(level)需要沿著靜態(tài)鏈向上找 level 層才能拿到對(duì)應(yīng)過程的棧起始地址。很多初版代碼在這里直接返回 0導(dǎo)致嵌套過程一調(diào)用就棧錯(cuò)亂。這也是為什么上課總強(qiáng)調(diào)“先畫棧幀布局圖再寫解釋器”。4.4 實(shí)驗(yàn)驗(yàn)證走一遍完整編譯流程完成了 Scanner、Parser、Table、Interpreter 之后用一個(gè)最小的 PL0 程序驗(yàn)證全流程VAR x; BEGIN x : 1; WRITE x END.這一行程序的編譯產(chǎn)物應(yīng)該是INT分配一個(gè)變量槽LIT 1壓入常量STO存入 xLOD讀回 xWRITE對(duì)應(yīng)的指令輸出棧頂值。我在本地跑通這五步之后才敢往文法里加 IF 和 WHILE。建議你也用同樣的順序逐步擴(kuò)展不要一上來就寫全部文法。5. 實(shí)驗(yàn)報(bào)告與踩坑記錄這些雷我替你先踩了5.1 實(shí)驗(yàn)報(bào)告的組織方式別寫成使用說明書GDUT 的實(shí)驗(yàn)報(bào)告一般要求包含實(shí)驗(yàn)?zāi)康?、算法設(shè)計(jì)、關(guān)鍵代碼、測(cè)試截圖和問題分析。很多同學(xué)把報(bào)告寫成了代碼注釋的搬運(yùn)工這是最吃虧的。老師真正想看的是兩樣?xùn)|西一是你對(duì)“為什么這樣設(shè)計(jì)”的說明比如為什么選遞歸下降而不是 LR、符號(hào)表為什么要分層二是你遇到的具體問題和排查過程這部分才是報(bào)告里最有說服力的原創(chuàng)內(nèi)容。我的建議是報(bào)告結(jié)構(gòu)固定為五段式文法設(shè)計(jì)用 EBNF 描述你的語言、算法流程圖狀態(tài)轉(zhuǎn)換圖或遞歸下降函數(shù)調(diào)用關(guān)系、核心代碼只選取詞法難點(diǎn)和語義動(dòng)作掛接點(diǎn)、測(cè)試用例至少三組包含一組錯(cuò)誤輸入的報(bào)錯(cuò)截圖、問題記錄每個(gè)問題按現(xiàn)象、原因、解決三段寫。CBC00.png、CBC.png 這些可視化圖片放在“測(cè)試用例”一節(jié)作為運(yùn)行結(jié)果的直接證據(jù)。5.2 五個(gè)高頻翻車現(xiàn)場(chǎng)現(xiàn)象、原因、解決三步定位第一個(gè)坑運(yùn)行 Parser.class 直接報(bào) UnsupportedClassVersionError?，F(xiàn)象是java Parser命令拋出版本不支持異常或者提示類文件版本錯(cuò)誤。原因是編譯這個(gè) class 的 JDK 版本和當(dāng)前運(yùn)行環(huán)境的 JDK 版本不匹配class 文件頭部的 major version 對(duì)應(yīng)不同的 JDK 發(fā)行版。解決方法是先反編譯看版本號(hào)再?zèng)Q定安裝哪個(gè)版本。javap -verbose Parser.class | grep major versionjavap -verbose會(huì)輸出 class 文件的完整元信息grep major version直接過濾出版本號(hào)。major 52 對(duì)應(yīng) JDK 855 對(duì)應(yīng) JDK 1161 對(duì)應(yīng) JDK 17?？吹桨姹咎?hào)之后裝對(duì)應(yīng)版本的 JDK或者直接用當(dāng)前 JDK 重新編譯源碼哪個(gè)方便用哪個(gè)。第二個(gè)坑1abc這類輸入沒有在詞法階段報(bào)錯(cuò)?，F(xiàn)象是詞法分析器把1abc拆成 NUMBER(1) 和 IDENT(abc)語法分析居然通過了運(yùn)行結(jié)果錯(cuò)誤。原因是數(shù)字識(shí)別分支只認(rèn)數(shù)字沒有檢查數(shù)字結(jié)束后緊跟著的字符是不是字母。解決方法是讀數(shù)字后加一個(gè)判斷if (isdigit(src[pos])) { size_t start pos; while (pos src.size() isdigit(src[pos])) pos; if (pos src.size() isalpha(src[pos])) { std::cerr 詞法錯(cuò)誤: 數(shù)字后不能直接跟字母\n; return ; } return NUMBER( src.substr(start, pos - start) ); }這段多出來的判斷能讓非法輸入在一開始就被攔下而不是跑到語法階段產(chǎn)生一串看不懂的錯(cuò)誤。第三個(gè)坑變量未聲明卻通過了語法分析。現(xiàn)象是BEGIN x : 1 END;這種程序沒在 VAR 段聲明 x語法分析沒報(bào)錯(cuò)運(yùn)行時(shí)棧操作亂套。原因是語法分析只檢查了文法結(jié)構(gòu)沒在語義動(dòng)作里查符號(hào)表。解決方法是 Parser 在處理ident : expression之前先調(diào)用Table.find(ident)查不到就輸出“未聲明標(biāo)識(shí)符”并中止編譯這一步也叫語義分析的基礎(chǔ)檢查是扣分重災(zāi)區(qū)。第四個(gè)坑嵌套過程里同名變量互相覆蓋。現(xiàn)象是 procedure A 聲明了 var xprocedure B 也聲明了 var xB 里改 x 之后回到 A 里發(fā)現(xiàn) x 也被改了。原因是符號(hào)表只做了一層沒有按過程分層維護(hù)作用域。解決方法是每進(jìn)入一個(gè) block 新建一層符號(hào)表查變量時(shí)從當(dāng)前層往上逐層找當(dāng)前層沒有就找上一層找不到才報(bào)未聲明。這就是 4.2 里Table需要擴(kuò)展成多層鏈表的原因只靠一個(gè)LinkedHashMap支撐不了嵌套過程。第五個(gè)坑zip 解壓后 class 文件打不開運(yùn)行直接崩潰?，F(xiàn)象是解壓后某個(gè) class 文件用 javap 都反編譯不了提示zip END header not found或者 EOFException。原因有兩種可能zip 包是偽加密加密標(biāo)志位被置位但文件內(nèi)容并沒真正加密一部分解壓工具會(huì)誤報(bào)或者壓縮包本身不完整某個(gè)文件在傳輸中斷裂。解決方法是先判斷偽加密用 7-Zip 打開 zip 包如果能看到文件列表且能正常預(yù)覽內(nèi)容但解壓時(shí)報(bào)錯(cuò)基本就是偽加密。這種情況下用工具修復(fù)加密標(biāo)志位或者換用能忽略偽加密的解壓工具重新解壓。如果確認(rèn)是文件損壞檢查壓縮包里的文件大小和 README 記錄是否一致對(duì)不上就重新下載。這個(gè)問題的排查順序是先看壓縮包 CRC再單文件校驗(yàn)最后才考慮是不是偽加密。5.3 一條普適的排錯(cuò)路徑從報(bào)錯(cuò)現(xiàn)象反推階段編譯器是一個(gè)多階段流水線出問題時(shí)先不要亂猜按階段定位能省一半時(shí)間。token 流錯(cuò)了是詞法階段問題token 對(duì)但語法樹構(gòu)造失敗是語法階段問題語法通過但運(yùn)行時(shí)棧亂是符號(hào)表或指令生成問題指令序列對(duì)著呢但結(jié)果錯(cuò)是運(yùn)算實(shí)現(xiàn)問題?，F(xiàn)象排查階段首選檢查點(diǎn)token 輸出不對(duì)詞法分析雙字符運(yùn)算符分支、數(shù)字邊界出現(xiàn) “expected …”語法分析遞歸下降函數(shù)是否漏調(diào)用advance()運(yùn)行時(shí)報(bào)棧越界語義分析變量是否登記符號(hào)表、層差計(jì)算編譯通過但結(jié)果錯(cuò)代碼生成OPR 運(yùn)算號(hào)映射是否正確6. 課后擴(kuò)展給 PL0 加三樣?xùn)|西讓答辯老師眼前一亮6.1 擴(kuò)展一給 term 加乘除運(yùn)算練習(xí)優(yōu)先級(jí)掛接標(biāo)準(zhǔn) PL0 的term只處理乘和除有的實(shí)驗(yàn)版本連乘除都沒有。加乘除很簡單難點(diǎn)不在詞法——*和/本來就是單字符運(yùn)算符——而在語法函數(shù)里運(yùn)算符的保存時(shí)機(jī)。我第一次寫時(shí)直接這樣寫void term() { factor(); while (tok MUL || tok DIV) { advance(); factor(); emit(tok MUL ? Fct.OPR_MUL : Fct.OPR_DIV); } }這段代碼有個(gè)隱藏 bugadvance()已經(jīng)把tok更新成下一個(gè) token 了emit里的tok MUL判斷用的根本不是剛才讀到的運(yùn)算符指令生成必然錯(cuò)位。正確做法是先把運(yùn)算符存下來再前進(jìn)void term() { factor(); while (tok MUL || tok DIV) { int op tok; // 關(guān)鍵先保存當(dāng)前運(yùn)算符 advance(); // 再讀下一個(gè) token factor(); emit(op MUL ? Fct.OPR_MUL : Fct.OPR_DIV); } }這種“先存后取”的細(xì)節(jié)就是遞歸下降分析里最常見的隱性 bug 來源。你在這份資源的報(bào)告里大概率也能看到類似的記錄。6.2 擴(kuò)展二給符號(hào)表加數(shù)組類型練習(xí)地址計(jì)算PL0 只有簡單變量加數(shù)組是不錯(cuò)的加分項(xiàng)。需要在Symbol里增加上下界字段在factor和賦值語句里解析下標(biāo)表達(dá)式代碼生成時(shí)把下標(biāo)換算成偏移量。數(shù)組的坑在下標(biāo)越界運(yùn)行時(shí)要生成一條檢查指令下標(biāo)超出范圍就報(bào)錯(cuò)終止。這個(gè)擴(kuò)展能把符號(hào)表、語義檢查、代碼生成三個(gè)階段串起來練一遍。6.3 擴(kuò)展三用 Graphviz 導(dǎo)出語法樹答辯現(xiàn)場(chǎng)生成圖在 Parser 里收集語法樹節(jié)點(diǎn)輸出成 DOT 格式文件再用 Graphviz 生成 PNG。答辯時(shí)當(dāng)場(chǎng)跑一遍比 PPT 里的截圖更有說服力digraph ast { node0 [label:]; node1 [labelx]; node2 [label]; node3 [labely]; node4 [label2]; node0 - node1; node0 - node2; node2 - node3; node2 - node4; }這個(gè) DOT 文件對(duì)應(yīng)x : y 2的語法樹digraph聲明有向圖每個(gè)node定義一個(gè)點(diǎn)-定義父子關(guān)系。實(shí)戰(zhàn)時(shí)把這個(gè)思想延伸到完整 PL0在 Parser 的每個(gè)子函數(shù)里創(chuàng)建新節(jié)點(diǎn)并把子節(jié)點(diǎn)掛上去最后統(tǒng)一輸出。我做課設(shè)那會(huì)兒吃過最大的虧是把語義分析和代碼生成混在一個(gè)超大 switch 里寫調(diào)試一個(gè)錯(cuò)誤要翻幾百行代碼。從那以后我每次做編譯器實(shí)驗(yàn)都強(qiáng)制先把 Fct 指令集、Symbol 結(jié)構(gòu)和符號(hào)表接口定義好再動(dòng)手寫 Parser——接口穩(wěn)定了后面所有階段只是填實(shí)現(xiàn)細(xì)節(jié)。這套 GDUT 資源的報(bào)告里恰好也有類似的分階段設(shè)計(jì)記錄建議你先讀 README 再動(dòng)代碼。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取