簡介面向高校編譯原理課程學(xué)習(xí)者與實驗開發(fā)者這份資料圍繞教學(xué)型 PL/0 編譯程序的修改擴充展開可用于完成詞法分析、語法分析與語義處理等課程實驗適合需要對照源碼理解編譯前端改造過程的學(xué)生。壓縮包共 24 個文件約 644KB包含 PL/0 的 cpp 與 h 源碼、實驗報告文檔以及 dsp/dsw 工程配置、Debug 編譯產(chǎn)物和臨時文件便于直接打開工程復(fù)現(xiàn)實驗并核對輸出。內(nèi)容覆蓋保留字 ELSE、FOR、TO、DOWNTO、RETURN 的加入運算符 、-、、-- 的擴充不等號由 # 改為 以及條件語句 ELSE 子句的實現(xiàn)等要求可幫助讀者定位詞法表、語法規(guī)則與語義動作的修改點。已有 790 人學(xué)習(xí)資源中的源碼、報告和工程文件可用于參考實驗組織方式、檢查實現(xiàn)思路與整理實驗文檔適合在課程設(shè)計或驗收前查漏補缺。1. 一份 PL/0 實驗包為什么卡人的總是保留字和 ELSEPL/0 的名聲是“小”十幾個保留字、幾個遞歸過程、百來行核心代碼看起來一天就能吃透。但某高校編譯原理課程的這份實驗包真正讓人返工兩三輪的從來不是遞歸下降的主干而是兩件小活往保留字表里塞進新詞之后標識符識別突然對不上號把if-then擴成帶 ELSE 語句的分支之后跳轉(zhuǎn)指令回填位置差一條指令運行結(jié)果忽大忽小。這份實驗包給的是能直接編譯運行的 PL/0 骨架詞法掃描、語法分析、符號表管理和 P-code 解釋執(zhí)行四層齊全附帶若干示例程序適合剛學(xué)完語法分析、想在一個晚上跑通完整鏈路的人也適合需要交課程設(shè)計、想弄清楚“文法改一行、代碼改一片”到底該改在哪的讀者。下面按我拆包時實際動手的順序記錄。2. 拆開 PL/0 實驗包的骨架四個模塊的職責(zé)邊界與改動點很多人拿到包第一件事是瞎翻代碼翻到statement()就開始改改完之后發(fā)現(xiàn)編譯能過、運行結(jié)果錯再回頭懷疑解釋器。我的習(xí)慣是先畫一張職責(zé)邊界表把“誰產(chǎn)生指令、誰消費指令、誰只讀不寫”釘死后面的每一次改動都能落到具體文件上排錯范圍立刻縮小一半。2.1 文件職責(zé)表先定位改動點再動手不同版本的實驗包文件切分方式不完全一樣有的拆成六個.c文件有的合成一個pl0.c但邏輯邊界是一致的。把邏輯模塊和物理文件對應(yīng)清楚再判斷擴展 ELSE 語句需要觸碰哪幾處。邏輯模塊典型文件關(guān)鍵符號職責(zé)擴展 ELSE 是否必改詞法lexer.cgetsym、ch、id、num跳空白、切標識符/數(shù)字/界符、判保留字是新增else詞語法parser.cblock、statement、condition、expression遞歸下降邊解析邊調(diào)gen是if 分支要重寫代碼生成codegen.cgen、cx、code[]輸出 P-code回填跳轉(zhuǎn)地址是新增一條JMP符號表symtab.ctable[]、btab[]、enter、position名字、層級、地址分配否解釋執(zhí)行interpret.cbase、interp、s[]按code[]逐條執(zhí)行否除非新增操作符公共頭pl0.hSYM_*、OPR_*、外置全局量常量與全局狀態(tài)是加SYM_ELSE表里“否”的那一行最值得注意符號表和解釋器在 ELSE 擴展中完全不動。這是 PL/0 結(jié)構(gòu)帶來的便利——ELSE 只是控制流不引入新作用域、不引入新類型、不需要新的運行時原語。凡是有人告訴你“ELSE 要在解釋器里加分支”基本都是把JMP和JPC記混了這兩個操作碼在原始解釋器里本來就實現(xiàn)好了。提示改之前先把這份表抄進實驗報告評審時能直接說明改動范圍比事后回憶靠譜得多。2.2 詞法層保留字、標識符、界符在一趟掃描里怎么分家PL/0 的詞法掃描是一趟式的getsym()被語法分析反復(fù)調(diào)用每次至少吃掉一個詞法單元。核心判定順序是固定的先跳空白再按首字符分三路——字母走標識符/保留字數(shù)字走無符號整數(shù)其余走界符表。第三路里最容易翻車的是雙字符界符:、、、必須先讀第二個字符再決定否則:會被單獨吐出去語法分析端立刻報“缺少:”。/* lexer.c —— getsym 主流程節(jié)選 */ void getsym(void) { while (ch || ch \t || ch \r || ch \n) getch(); /* 跳過空白注意不要吞掉 EOF */ if (isalpha(ch)) { /* 字母開頭標識符或保留字 */ int n 0; do { if (n ID_MAX - 1) id[n] ch; /* 超長截斷但繼續(xù)掃描 */ getch(); } while (isalnum(ch)); id[n] \0; sym lookup_kw(id); /* 命中返回保留字編號否則 SYM_IDENT */ } else if (isdigit(ch)) { /* 數(shù)字開頭無符號整數(shù) */ num 0; do { num num * 10 (ch - 0); getch(); } while (isdigit(ch)); sym SYM_NUMBER; if (num NUM_MAX) error(31); /* 溢出要在詞法階段就攔住 */ } else if (ch :) { /* 雙字符界符必須先看第二個字符 */ getch(); if (ch ) { sym SYM_BECOMES; getch(); } else sym SYM_COLON; } else if (ch ) { getch(); if (ch ) { sym SYM_LEQ; getch(); } else if (ch ) { sym SYM_NEQ; getch(); } else sym SYM_LSS; } else { sym SYM_NULL; /* 非法字符交給上層報錯 */ getch(); } }幾個參數(shù)要交代清楚。ID_MAX是標識符緩沖長度一般取 32 就夠但循環(huán)里我用的是“超長截斷但繼續(xù)掃描”的寫法——如果直接break剩余字符會被下一輪當(dāng)成新的標識符錯誤信息會指向一個根本不存在的名字排查時極其迷惑。NUM_MAX對應(yīng)目標機整數(shù)上限標準 PL/0 取 32767超了必須報錯而不是靜默截斷否則運行期會得到一個莫名其妙的負數(shù)。lookup_kw是唯一與保留字表打交道的地方第 3 章會專門重寫它。else這個詞加進來之后詞法層面只需要動兩處保留字表里加一條記錄pl0.h里加SYM_ELSE枚舉。但有個順序問題——枚舉值一旦插入中間位置所有用數(shù)字硬編碼的地方都會錯位。安全做法是把SYM_ELSE追加到枚舉尾部或者干脆全部用符號名不寫數(shù)字。2.3 語法層表達式、語句、分程序的三級遞歸結(jié)構(gòu)PL/0 的語法分析是教科書式遞歸下降三層嵌套block處理分程序常量、變量、過程聲明 復(fù)合語句statement處理語句expression → term → factor處理表達式。三者的調(diào)用關(guān)系是單向的statement調(diào)expression求條件expression回頭不會調(diào)statement所以不存在相互遞歸的復(fù)雜度。原始版本的 if 語句處理邏輯很簡短理解它是后面改 ELSE 的前提/* parser.c —— 原版 if 語句無 else */ case SYM_IF: getsym(); condition(); /* 生成條件表達式代碼結(jié)果留在棧頂 */ if (sym SYM_THEN) getsym(); else error(16); /* 缺少 then */ { int jpc cx; /* 記住 JPC 指令在 code[] 中的下標 */ gen(JPC, 0, 0); /* 占位條件為假時跳轉(zhuǎn)地址待回填 */ statement(); /* then 分支 */ code[jpc].a cx; /* 回填跳到 then 分支之后 */ } break;cx是“下一條指令將寫入的位置”也就是當(dāng)前代碼區(qū)指針gen(op, l, a)往code[cx]寫指令然后cx。這里的關(guān)鍵動作是“先占位、后回填”——gen的時候還不知道跳轉(zhuǎn)目標在哪只能寫 0等 then 分支編譯完cx正好指向分支之后的指令再把地址塞回去。這個模式會在 ELSE 擴展里用兩次一次給JPC一次給JMP。真正容易忽略的是condition()之后棧的狀態(tài)條件表達式執(zhí)行完棧頂恰好有一個 0/1 值JPC的語義是“彈出棧頂為 0 則跳轉(zhuǎn)”。所以JPC必須緊跟在條件代碼之后中間不能插入任何其他指令。這一點決定了THEN之前不能做任何額外操作包括“為了調(diào)試打印點東西”——加一條gen就破壞棧平衡。2.4 符號表與運行時棧為什么 ELSE 擴展可以完全不碰它們符號表部分由table[]名字表和btab[]分程序表組成enter負責(zé)登記名字position負責(zé)在作用域鏈上查找。變量的地址不是絕對地址而是“層差 偏移”的二元組運行時由base()沿著動態(tài)鏈回溯到目標層再加上偏移定位。ELSE 擴展不涉及任何新名字、新作用域、新類型所以這兩個數(shù)據(jù)結(jié)構(gòu)一行都不用改。語法分析進入statement時沒有enter調(diào)用level和dx保持不變btab里也不會多一條記錄。換句話說if ... then ... else ...里的兩條分支共享同一個分程序上下文變量可見性完全一致這也是 Pascal 系語言的標準行為。運行時棧同理。JMP和JPC在標準解釋器的switch里都有現(xiàn)成實現(xiàn)JPC彈棧判斷后修改pcJMP直接修改pc。只要回填的地址正確執(zhí)行流就正確。所以排查運行結(jié)果異常時第一優(yōu)先級不是去讀interpret.c而是把code[]反匯編打出來逐條核對跳轉(zhuǎn)目標。這個習(xí)慣我保持了很久能省掉大量猜測。3. 保留字識別改造從全表 strcmp 到分桶查表的落地保留字識別在實驗包里通常是一個十行左右的小函數(shù)全表線性strcmp命中即返回。教學(xué)代碼這么寫沒問題但只要你往里加詞就會開始暴露兩個問題一是每次標識符識別都要走完整張表程序里變量越多越虧二是新增保留字后如果忘了同步SYM_*枚舉編譯器會把else當(dāng)普通標識符放過去語法分析端報出來的錯誤位置完全對不上真實原因。第 3 章就是把這個函數(shù)重做一遍并把驗證手段補齊。3.1 三種組織方式的對比與選型保留字表怎么存取決于你更在意哪一點改動量、查找速度還是出錯時的可診斷性。常見做法有三種我在不同場合都用過。方案平均比較次數(shù)改動量主要風(fēng)險適用場景線性數(shù)組 strcmp約 n/2n≈14 時約 7 次最小加一行即可詞越多越慢容易漏改枚舉課程實驗原始形態(tài)按首字母/長度分桶約 12 次中等需要建桶桶下標算錯導(dǎo)致漏查保留字 1540 個完美散列/查表1 次較大需要生成器生成表與源碼不同步工業(yè)級關(guān)鍵字集對 PL/0 這種規(guī)模我一般選分桶比線性快一截比完美散列省事而且桶的構(gòu)造邏輯本身可以寫在源碼里評審時一眼能看懂。關(guān)鍵點是桶的下標必須由函數(shù)算不能靠手寫常量——手寫常量就是把“表”和“哈希函數(shù)”兩份真相分開維護早晚不同步。3.2 用拉鏈法把保留字表掛進桶里下面這段是可直接替換的版本靜態(tài)表kw_pool是唯一真相啟動時由kw_init按哈希值掛鏈lookup_kw只做“算下標、走鏈、比較”。/* lexer.c —— 分桶 拉鏈的保留字表 */ #define KW_BUCKET 16 #define KW_MAX 32 typedef struct { const char *name; int sym; /* 必須與 pl0.h 中的 SYM_* 枚舉嚴格一致 */ int next; /* 同桶內(nèi)下一條下標-1 表示鏈尾 */ } kw_entry; static const kw_entry kw_pool[] { {begin, SYM_BEGIN}, {call, SYM_CALL}, {const, SYM_CONST}, {do, SYM_DO}, {else, SYM_ELSE}, {end, SYM_END}, {if, SYM_IF}, {odd, SYM_ODD}, {procedure, SYM_PROCEDURE}, {read, SYM_READ}, {then, SYM_THEN}, {var, SYM_VAR}, {while, SYM_WHILE}, {write, SYM_WRITE}, }; static kw_entry kw_tab[KW_MAX]; /* 運行期副本next 字段會被改寫 */ static int kw_head[KW_BUCKET]; static int kw_cnt; /* FNV-1a 簡化版位運算夠快且不需要額外鏈接庫 */ static unsigned kw_hash(const char *s) { unsigned h 2166136261u; while (*s) { h ^ (unsigned char)*s; h * 16777619u; } return h % KW_BUCKET; } void kw_init(void) { int i; kw_cnt (int)(sizeof(kw_pool) / sizeof(kw_pool[0])); if (kw_cnt KW_MAX) error(99); /* 表溢出編譯期就該攔 */ for (i 0; i KW_BUCKET; i) kw_head[i] -1; for (i 0; i kw_cnt; i) { unsigned b kw_hash(kw_pool[i].name); kw_tab[i] kw_pool[i]; kw_tab[i].next kw_head[b]; /* 頭插順序無所謂 */ kw_head[b] i; } } int lookup_kw(const char *name) { int i kw_head[kw_hash(name)]; while (i ! -1) { if (strcmp(kw_tab[i].name, name) 0) return kw_tab[i].sym; i kw_tab[i].next; } return SYM_IDENT; /* 未命中即普通標識符 */ }邏輯上有三點需要說明。第一kw_pool用const修飾把“源表”和“運行期表”分開kw_init只寫kw_tab這樣即使某個環(huán)節(jié)把鏈表寫壞了下次初始化依然能恢復(fù)正確狀態(tài)調(diào)試時少一個變量。第二kw_hash用的是 FNV-1a字符串短的時候性能差別不明顯但它分布均勻、實現(xiàn)只有三行比“首字母減 a 再取?！边@種寫法穩(wěn)得多——后者在大小寫混排或新增以數(shù)字結(jié)尾的詞時容易撞成一堆。第三頭插法意味著同桶內(nèi)的順序與聲明順序相反這無所謂因為查找只關(guān)心命中與否。參數(shù)方面KW_BUCKET取 16 對應(yīng) 14 個保留字平均每桶不到一條比全表掃描少一個數(shù)量級的比較如果后續(xù)擴展到 30 個以上把它改成 32 或 64 即可kw_hash里的取模會自動跟隨不需要改其他地方。KW_MAX是硬上限比kw_pool實際條數(shù)大一些留余量一旦超了就在初始化階段報錯而不是運行時越界寫內(nèi)存——這種錯誤在實驗環(huán)境里極難定位。lookup_kw的返回值直接決定getsym里sym的取值所以它的契約必須寫死命中返回對應(yīng)保留字的SYM_*未命中返回SYM_IDENT絕不返回 0 或 -1。這一點在原始代碼里經(jīng)常被寫成“未命中返回 0”一旦SYM_NULL恰好也是 0非法字符和普通標識符就分不開了。3.3 編譯期自檢一張覆蓋表把回歸擋住改完詞法最怕的是“看起來能用”。我一般會在實驗包里加一個自檢入口把每個保留字單獨寫成一個最小程序跑一遍確認都能被正確識別再補幾個“長得像保留字”的標識符確認不會被誤傷。# 逐個保留字走查每個詞拼一個最小可編譯片段 for kw in begin call const do else end if odd procedure read then var while write; do printf %s\n $kw /tmp/probe.pl0 ./pl0c /tmp/probe.pl0 /tmp/probe.out 21 grep -q SYM_$(echo $kw | tr a-z A-Z) /tmp/probe.out \ echo [OK] $kw \ || echo [FAIL] $kw - $(head -1 /tmp/probe.out) done這段腳本依賴編譯器帶一個-d之類的詞法調(diào)試開關(guān)把每次getsym的結(jié)果打出來。如果沒有這個開關(guān)就臨時在getsym返回前加一行打印驗完再刪。腳本本身不復(fù)雜價值在于把“我記得改過”變成“每次都跑一遍”。緊接著要跑反向用例elsewhere、ifx、end1、do_2這類名字必須被識別為SYM_IDENT。原始線性表版本偶爾會在strncmp的長度參數(shù)上寫錯導(dǎo)致前綴匹配——elsewhere被當(dāng)成else后面跟一個where報錯位置飄到下一行這種 bug 靠讀代碼很難發(fā)現(xiàn)靠用例一秒鐘暴露。3.4 枚舉與表的同步機制最后一件事SYM_*枚舉和kw_pool的sym字段是兩份數(shù)據(jù)天然有不同步的風(fēng)險。低成本的做法是在kw_init里加一次斷言式檢查——遍歷kw_pool確認每個sym值都在合法區(qū)間內(nèi)且互不重復(fù)。重復(fù)檢測用一個位圖幾十行以內(nèi)解決。/* kw_init 末尾追加枚舉值唯一性檢查 */ static void kw_check(void) { static unsigned char seen[SYM_MAX]; int i; for (i 0; i kw_cnt; i) { int s kw_pool[i].sym; if (s SYM_NULL || s SYM_MAX) error(98); /* 越界 */ if (seen[s]) error(97); /* 重復(fù) */ seen[s] 1; } }這類自檢不是“為了規(guī)范”是實打?qū)嵤r間的。血淚經(jīng)驗是插入新枚舉值到中間導(dǎo)致if和then的編號整體后移詞法層照舊返回舊編號語法層switch全部走空分支——編譯器不報錯生成的代碼是空的運行結(jié)果一切正常因為什么都沒執(zhí)行。這種“靜默錯”最難查加一次唯一性檢查就徹底堵死。4. ELSE 語句落地文法、遞歸下降、P-code 回填的三處聯(lián)動ELSE 語句的擴展是這個實驗包里改動鏈條最長的一處文法要改、語法分析要改、代碼生成要多一條JMP三處任何一處不同步表現(xiàn)都是“能編譯、結(jié)果錯”。我按依賴順序拆成四步走每一步都能單獨驗證。4.1 文法改造與 FIRST/FOLLOW 快速自檢原始 if 語句的產(chǎn)生式只有一支改成兩支帶 else 和不帶 else之后必須確認它不會和后續(xù)語句的首符集沖突。語句 :: 賦值語句 | 條件語句 | 循環(huán)語句 | 復(fù)合語句 | 讀語句 | 寫語句 | ε 條件語句 :: if 子句 then 子句 [ else 子句 ] if 子句 :: IF 條件 then 子句 :: THEN 語句 else 子句 :: ELSE 語句用方括號表示可選而不是拆成兩條產(chǎn)生式是因為遞歸下降實現(xiàn)里“可選”對應(yīng)的是if (sym SYM_ELSE)一次判斷拆成兩條反而要在入口處做回溯或者提取公因子。檢查點有兩個then 子句的 FOLLOW 集里含ELSE所以語句不能以ELSE開頭——PL/0 的語句首符集里確實沒有ELSE這一條安全條件語句的 FOLLOW 集里含END、;、ELSE其中ELSE的出現(xiàn)正是“懸掛 else”的來源。4.2 遞歸下降里的懸掛 else 與向前看一個符號PL/0 的語法分析器只維護一個當(dāng)前符號sym沒有回溯。這在處理懸掛 else 時反而是優(yōu)勢statement()解析完 then 分支返回后sym恰好是緊隨其后的那個詞法單元如果是ELSE就歸當(dāng)前這個if如果不是就歸外層。這天然實現(xiàn)了“else 就近匹配”和 Pascal 的語義一致。/* parser.c —— if 語句含 else先占位后回填 */ case SYM_IF: { int jpc, jmp -1; getsym(); condition(); /* 結(jié)果 0/1 留在棧頂 */ jpc cx; gen(JPC, 0, 0); /* 條件為假 → 跳到 else 段起點 */ if (sym SYM_THEN) getsym(); else error(16); statement(); /* then 分支sym 停在分支之后的符號上 */ if (sym SYM_ELSE) { jmp cx; gen(JMP, 0, 0); /* then 走完 → 跳過 else 段 */ code[jpc].a cx; /* 回填JPC 落到 else 段第一條指令 */ getsym(); statement(); /* else 分支 */ } code[jpc].a (jmp 0) ? code[jpc].a : cx; /* 無 else 時 JPC 落到 if 之后 */ if (jmp 0) code[jmp].a cx; /* 回填JMP 落到 if 之后 */ break; }這段代碼里有三處細節(jié)值得展開。第一jmp初始化為 -1 而不是 0因為 0 是合法的指令下標用它當(dāng)“未設(shè)置”標志會在 if 語句位于程序第一條指令時誤判。第二code[jpc].a在帶 else 和不帶 else 兩種情況下回填的值不同帶 else 時指向 else 分支起點不帶 else 時指向 if 之后——后者等價于“沒有要跳過的內(nèi)容”所以可以省略回填但顯式寫出來更清楚。第三JMP的下標必須在statement()之前就記下來因為 then 分支的編譯會推進cx事后再想找位置就得靠搜索容易出錯。關(guān)于懸掛 else還有一個容易踩的點如果 then 分支里嵌套了一個不帶 else 的 if內(nèi)層 if 會把外層想留給自己的ELSE搶走。這不是 bug是“就近匹配”的必然結(jié)果標準 Pascal 也是這個行為。如果你的實驗要求里明確寫了“else 與最近的未匹配 if 配對”那這段代碼就是對的如果要求是“與外層配對”就必須在 then 分支里禁止裸 if 語句或者引入begin...end強制包裹。動手前先確認要求別寫完才發(fā)現(xiàn)語義不對。4.3 目標代碼生成JPC 與 JMP 的回填格式gen本身很樸素作用就是把四元組寫進code[]并推進cx。真正決定正確性的是回填時機和地址語義。/* codegen.c —— 指令生成與地址回填 */ void gen(int op, int l, int a) { if (cx CODE_MAX) error(30); /* 代碼區(qū)溢出 */ code[cx].f op; /* 操作碼 */ code[cx].l l; /* 層級跳轉(zhuǎn)指令恒為 0 */ code[cx].a a; /* 目標地址或立即數(shù) */ cx; }參數(shù)含義需要明確l對JMP/JPC沒有意義一律寫 0a在LIT里是立即數(shù)在LOD/STO里是偏移在JMP/JPC里是絕對指令下標。正因為a的語義隨操作碼變化回填時最容易發(fā)生的錯誤是“把 bx 的相對偏移寫進了 a”——JPC的a必須是絕對下標解釋器執(zhí)行pc code[pc].a是直接賦值不做任何加法。一個完整的 if-else 結(jié)構(gòu)編譯出來應(yīng)該是這樣的形態(tài)用一組具體數(shù)字看得更清楚下標指令含義10JPC 0 14條件為假跳到 14else 段1112...then 分支代碼13JMP 0 18then 結(jié)束跳過 else 段1417...else 分支代碼18...if 語句之后的代碼這張表是我的排錯模板。每次結(jié)果不對先把code[]打出來找JPC和JMP看它們的目標下標是不是恰好落在“else 段第一條”和“if 之后第一條”上。對不上就是回填次序錯了對上了還錯就是解釋器或者別的地方有問題判斷路徑非常干脆。4.4 用對照程序驗證跳轉(zhuǎn)鏈驗證不能只跑一個“結(jié)果是 1”的用例必須覆蓋四條路徑條件真 有 else、條件假 有 else、條件真 無 else、條件假 無 else。下面這個程序一次跑完前兩條。{ test_else.pl0 —— 覆蓋 if-else 的兩條分支 } var a, b; begin a : 1; b : 0; if a 0 then b : 10 else b : 20; write(b); { 期望輸出 10 } if a 0 then b : 30 else b : 40; write(b) { 期望輸出 40 } end.兩個write的輸出必須分別是 10 和 40。如果第一個輸出 20說明JPC的目標指到了 else 段但條件判斷反了如果第一個輸出 10、第二個輸出 30說明JMP沒生效then 分支執(zhí)行完直接掉進了 else 段。這兩種現(xiàn)象對應(yīng)兩種不同的回填錯誤靠輸出值就能把范圍鎖定到一行代碼。再把 else 分支換成嵌套 if確認跳轉(zhuǎn)鏈沒有串位{ test_nest.pl0 —— else 分支里再嵌 if-else } var x, y; begin x : 2; y : 0; if x 1 then if x 5 then y : 1 else y : 2 else y : 3; write(y) { 就近匹配期望輸出 2 } end.這個用例的價值在于它會同時考驗“就近匹配”和三層跳轉(zhuǎn)的回填。如果輸出 3說明內(nèi)層 if 的 else 被外層搶走了語法分析的實現(xiàn)與預(yù)期語義不一致如果輸出 1說明條件比較方向錯了。跑通這四個用例ELSE 擴展的代碼生成部分基本可以判定為正確。5. 避坑排查五條讓實驗結(jié)果飄掉的細節(jié)下面五條是我在拆這類實驗包時反復(fù)遇到的真實故障每條都按“現(xiàn)象 → 原因 → 解決”記錄可以直接當(dāng)排錯清單用?，F(xiàn)象一加了else之后變量名elsewhere、else1報“非法符號”。原因多半是保留字判定用了前綴比較strncmp(id, else, 4)返回 0 就當(dāng)命中elsewhere被切成elsewhere。解決是把比較改成等長判定strcmp或者“先比長度再比內(nèi)容”并在反向用例里加上三五個以保留字為前綴的標識符作為固定回歸項?，F(xiàn)象二條件為真時走了 else 分支。先別懷疑JPC的實現(xiàn)九成是condition()生成的代碼把結(jié)果壓反了或者JPC被插在了條件代碼中間。檢查方法是看JPC是否緊跟在條件表達式的最后一條指令之后中間只要夾了一條LOD或OPR棧頂就不是條件值。這類錯誤在嵌套表達式里特別隱蔽因為外層看起來完全正?！，F(xiàn)象三then 分支只有一條語句時正確有兩條就崩。原因通常是語句之間的分號處理。PL/0 的復(fù)合語句是begin 語句; 語句; ... end最后一個分號可有可無如果statement()里沒有正確吃掉分隔符第二條語句會被當(dāng)成新語句的開始而cx已經(jīng)推進回填位置整體偏移。解決是回到block的語句循環(huán)確認“分號在語句之間、不在語句之后”的處理邏輯?，F(xiàn)象四JMP的目標地址總是差 1。這是最經(jīng)典的回填錯誤code[jmp].a cx寫在了cx之前或之后的位置不對。cx的語義是“下一條待寫指令的下標”所以回填必須在“else 分支已經(jīng)編譯完、接下來要寫下一條指令”的那一刻執(zhí)行。如果提前一條跳轉(zhuǎn)會落在 else 分支的最后一條指令上重復(fù)執(zhí)行一次如果晚一條會跳過 if 之后的第一條語句。用 4.3 那張下標表對照一眼能看出來?，F(xiàn)象五詞法改了、語法改了編譯通過運行時“什么都不做”。這是枚舉不同步的典型癥狀SYM_ELSE插在枚舉中間導(dǎo)致后續(xù)編號整體后移詞法層返回的是新編號而某個switch里還寫著舊編號的case落到了default的空分支。解決是把枚舉值全部改成顯式賦值SYM_IF 20這種或者在kw_init里加唯一性檢查讓問題在啟動階段就暴露。這類“靜默錯”比崩潰難查十倍值得多花十分鐘做防御。注意以上五條里前四條都能靠“打印code[]反匯編”快速定位第五條只能靠自檢。所以我在任何 PL/0 改造里都會保留一個-d編譯開關(guān)輸出詞法單元序列和 P-code 清單驗完再關(guān)掉。6. 進階驗證把 ELSE 擴成 ELSIF 并跑通三段式檢查ELSE 跑通之后很多人會順手想加ELSIF。這件事的難度不在語法而在“少一層嵌套、多一次跳轉(zhuǎn)”的等價變換是否徹底。我的做法是先把else if手寫成嵌套形式確認語義基線再做詞法層面的合并。6.1 兩種 ELSIF 實現(xiàn)路徑的取舍路徑一是在詞法層把elsif當(dāng)成新保留字語法層新增一條產(chǎn)生式代碼生成時把它展開成“else 分支里再套一個 if”。路徑二是干脆不做新關(guān)鍵字只允許else if連寫靠遞歸下降自然形成嵌套。后者零改動前者能少一層JMP但要多維護一個保留字和一條產(chǎn)生式。維度新增elsif關(guān)鍵字復(fù)用else if嵌套詞法改動加一條表項 一個枚舉無語法改動新增產(chǎn)生式需處理懸掛無生成代碼少一條JMP每層多一條JMP出錯風(fēng)險枚舉同步、優(yōu)先級基本為零適用場景分支鏈超過 4 層分支鏈 23 層實驗場景下我一般選第二條因為 PL/0 的程序規(guī)模小多幾條JMP對解釋執(zhí)行沒有可感知影響而少一處改動就少一處可能出錯的地方。真要練手第一條更有價值——它逼你重新走一遍第 3 章和第 4 章的全部流程。6.2 三段式檢查詞法、P-code、運行結(jié)果缺一不可不管選哪條路驗證都必須分三段做不能只看最終輸出。第一段查詞法把源程序喂給帶調(diào)試開關(guān)的編譯器確認每個else、elsif都返回正確的SYM_*elsewhere這類名字仍是SYM_IDENT。第二段查 P-code人工核對每個JPC和JMP的目標下標確保落在段邊界上用 4.3 那張表逐行比對。第三段才跑運行結(jié)果并且至少覆蓋“全真”“全假”“真假交替”三種輸入。# 三段式檢查的落地腳本詞法 → P-code → 運行 ./pl0c -d test_else.pl0 lex.log 21 # 第一段詞法單元序列 grep -c SYM_ELSE lex.log # 期望等于源文件里 else 的個數(shù) ./pl0c -p test_else.pl0 pcode.log 21 # 第二段P-code 反匯編 awk /JPC|JMP/ {print} pcode.log # 人工核對目標下標 ./pl0vm pcode.log # 第三段解釋執(zhí)行腳本里的-d和-p需要自己在實驗包里加加起來不到三十行但它把“憑感覺判斷對錯”變成了“看數(shù)據(jù)判斷對錯”。我吃過一次虧某個版本的JMP回填在“else 分支是空語句”時會指到下一條指令的中間輸出碰巧正確直到換了一個分支里有write的用例才暴露。從那以后我每次改完語法或代碼生成都強制走一遍這三段一段不過就不往下走。如果實驗要求交報告這三段日志本身就是最好的材料詞法日志證明保留字改造生效P-code 日志證明跳轉(zhuǎn)鏈正確運行輸出證明語義符合預(yù)期三樣?xùn)|西放一起比任何文字描述都有說服力。希望幫到你。本文還有配套的精品資源點擊獲取