原创 [語法分析]LR狀態集
由於識別表達式的工作已經委託給其他的分析器去做了，因此這一階段需要關注的產生式其實很少，它們是： Jerry -> BasicBlock <END> BasicBlock -> ε BasicBlock -> Senten
2020-06-14 09:43:50
原创 [錯誤處理]變量分析器 / 語法分析錯誤提示函數接口
變量分析器本身很簡單，它的錯誤處理不需要弄得太複雜，只對正反方括號做做驗證，其它的丟給表達式分析器或者LR分析器去弄就行了。（下面一段話中的括號均指方括號。） 大致的構想是這樣的：當需要反括號時，沒碰到反括號，直接提示錯誤
2020-06-14 09:43:50
原创 [語法分析]LR分析器與其它分析器的交互
Action表中還有一小部分沒有填完，就是LR分析器委託其他分析器識別非終結符的那一部分。其中包括在變量定義時委託VariableAnalyser識別變量，在識別循環條件或賦值語句等狀態中委託OperationAnalyser識別
2020-06-14 09:43:39
原创 [開發過程]符號表的測試
之前在詞法和語法分析部分都有測試，不過那些測試顯得很小打小鬧，而且比較麻煩。好在那都是不復雜的東西，測試負擔較小。而符號表這東西是語義分析需要用到的基礎結構，如果等到最後進行集成測試，出了bug還真不好找。所以這東西有必要單獨拿來
2020-06-14 09:43:39
原创 [語法分析]LR語法分析器的構造
LR分析器的consumeNonTerminal函數在上一節提到過，其實跟Goto表沒有關係：如果在分析器內部規約得到一個非終結符，那麼規約函數執行結束之後，馬上就會根據傳入宏的“leftPart”在Goto表中查找對應的目標狀態
2020-02-24 11:23:15
原创 [符號表]靜態地址管理符號表接口及使用原則
進入語義分析的首要任務是組織和管理變量符號。這一點有多種選擇，一種是類C/C++語言那樣的靜態處理，即將變量映射爲地址，運行時內存中根據地址取得變量值，這樣運行效率無論是從內存使用量和訪問速度上都會較高；而另一種就是可反射的符號表
2020-02-24 11:23:04
原创 [詞法分析]一個雛形
到了終結之前那一團散沙的時候了。先把幾個頭文件列出來。下面每一段代碼的首行註釋的內容表示包含這些代碼的文件的文件名。 /* const.h */ #ifndef _CONSTANT_H #define _CONSTANT_H type
2020-02-24 11:23:04
原创 [錯誤處理]面向經驗的玩意兒
錯誤處理的方法之一是認可錯誤的輸入，將它判定爲某一種正確輸入的變體，然後在報出錯誤後再其糾正它。這個過程很大程度上跟經驗相關，對於出錯的經驗越豐富，那麼就可以矯正越多種類的錯誤。在詞法分析中這一點體現得並不多——詞法本身很簡單，而
2020-02-24 11:23:04
原创 [語法分析]識別變量的分析器
變量這玩意兒本身很簡單，無非是一個標識符開頭，然後若干對中間夾着一個算數運算的正反方括號，而分析算術運算節點的任務又可以委託給專門的分析器來做，因此識別變量的分析器本身其實沒什麼需要做的。下面是它的數據結構。 struct Vari
2020-02-24 11:23:04
原创 [語法分析]無需產生式的分析器
算符優先分析用來處理表達式非常便捷，甚至你可以忘記算術運算相關的一切產生式。對於算符優先分析來說最重要的東西有三：運算符的優先級、元和結合方式。優先級在任務佈置時已經講過了；元很簡單，一般運算符都是二元的，只有正號和負號是一元的；
2020-02-24 11:23:04
原创 [開發過程]宏函數及調試
在使用了大量的宏來快速構建函數後，一個問題出現了：如果你發現某個地方出了bug，你得定位它，於是使用debugger，然而宏的“簡易”導致你進行了許多次“下一步”還是停留在使用宏的那一行。 當然也不是完全沒辦法，如果你曾經
2020-02-24 11:23:04
原创 [語法分析]完結篇
附件中包含了到目前爲止的所有文件，除了COOL目錄之外。 語法分析的功能基本上成熟了，調試也完成了，現在剩下將這些東西整合起來成爲一個沒有調試輸出（特別是內存分配調試）的整體了。首先要做的事情是，把COOL中的Queue/Stac
2020-02-24 11:23:04
原创 [詞法分析]解析輸入
詞法分析的最終目標是將輸入字符流變成一個個符號，因此還需要引入一個新的結構： /* datastruct.h */ struct Token { int line; // 所在行 AcceptType type
2020-02-24 11:23:04
原创 [語法分析]算符優先分析的實現及獨立測試
好了，現在來嘗試把那些該未實現的註釋給實現掉了。當然有兩個地方在上一節中本應該實現，它們是代碼塊1中的 // 將一個左括號壓入棧頂 // 實現爲 opana->opStack->push(opana->opStack,
2020-02-24 11:23:04
原创 [語法分析]前奏：怎麼擴展
現在完成的是一個詞法分析器，那麼怎麼將它與語法分析相連？ 話說，基本上所有的編譯器構造相關的文章都是把詞法分析丟在語法分析之前，類似這樣： 預處理（C語言爲代表，Jerry沒這一環） -> 詞法分析 -> 語法分析 -
2020-02-24 11:23:04