2025q1 Homework1 (ideas)

contributed by <DrXiao>

參照去年的期末專題列表後，目前選定以下專題來閱讀並撰寫我的疑惑與見解

Linux 核心專題: shecc
Linux 核心專題: 多核 RISC-V 模擬和 Linux 驗證

Linux 核心專題: shecc

其他相關素材或資料

疑問 1：shecc 的目標或限制

shecc 起初是為了教學為而建立的編譯器專案，自 2019 年便持續發展至今，老師也會在實體課堂、線上授課或是其他公開場合講解 shecc 時，數次提起 shecc 的設計理念。

在閱讀開發紀錄之前，我有粗略地知道 shecc 有以下目標、限制：

建立可自我編譯的編譯器
將 shecc 的程式碼限制在 xxxx 行以內
（這點我依稀記得是老師在某次授課時曾講過，希望可公開一個程式碼精簡的編譯器案例）
實作編譯器前端、中間表示式（IR）、建立 SSA 並實施與硬體無關的最佳化、輸出特定硬體架構的機器碼，涵蓋經典的編譯流程。

不過不論是去年的開發紀錄，抑或是 2020 年的開發紀錄，似乎對上面幾點沒有更深入的說明。

以第一點來說，雖然我知道 shecc 可以自我編譯，但我從過往的開發紀錄中沒有閱讀到：

為什麼要讓編譯器可以自己編譯自己？
這件事情可以帶來什麼好處？
與不能自我編譯的編譯器會有什麼樣具體的差別？
要讓編譯器可以自我編譯，大概哪些什麼地方要特別花功夫設計並實作？

上面列舉的 1 ~ 3 點或許是可以透過閱讀其他素材而得知觀念，但 shecc 作為一個可自我編譯編譯器的典範，我仍期待可以在今年的開發紀錄中，逐漸加入上面幾點的說明。我想至少以第 4 點來說，就可以 shecc 舉例說明，帶出要花時間處理的那些地方，讓閱讀者了解自我編譯的困難跟實作議題。

再來第二點「原始程式碼限制在 xxxx 行」，這點我想今年的開發紀錄便可以加入，可以與老師或過往投入的開發者討論，為什麼會要有前述的限制，並在今年的開發紀錄撰寫之。

像這點我就依稀知道，就是如前面所述「可公開一個程式碼精簡的編譯器案例」，但是否還有其他原因，我暫時不得而知，若有其他原因，也期待今年的開發紀錄涵蓋這些內容。

此外一旦有了某些限制，也會連帶影響到實作，所以「限制程式碼行數會連帶影響什麼事不能做或是受限？」也是一個可以撰寫的點。

同樣地，我也是依稀知道程式碼行數的限制會連帶到 lexer/parser 的實作。以 shecc 來說，目前並沒有實作前置處理器的功能，沒有做的一個原因是，一旦真的實作，程式碼行數便會大幅增長，這樣就超過程式碼行數的限制，導致 shecc 就不會是一個精簡的編譯器實作了。

第三點，因為 shecc 已涵蓋前面所提及的那些經典流程，同樣地，shecc 作為一個經典編譯器案例，去年已經有了那些流程的基本介紹，今年或許可以開始更深入地講解每個環節。

但反過來說，其實 shecc 也是有部份環節是沒有做到的，例如：

抽象語法樹（Abstract Syntax Tree）
與硬體架構有關的最佳化

為什麼沒有做這些事情，或許也是一個今年可以撰寫的點。

以上是我想到的，可以更深入說明的細節，並且如果 shecc 事實上還有其他設定目標，今年也可以一併列舉，做出一個目前為止的總結報告。

疑問 2：shecc 的發展歷史

這點是去年有了 GitHub issue#174 的討論，我才有的疑問。

上面給定的超連結，是當時候某位開發者利用 GitHub issue 提出疑問（詢問 ph1_ir_t 的使用方式），當時候看到之前貢獻的 vacantron 同學給出的回覆，令我有點意外：

The ph1_ir-related functionality, such as add_ph1_ir(), had been deprecated, but it still be preserved for the backward compatibility of @ChAoSUnItY 's work. Use add_insn() to build the IR instead.

原來 shecc 早在過往發展的某個時間點，就已經改用 insn 的結構體，以後者為主建立中間表示式並進行後續編譯工作，ph1_ir_t 則保留使用，但它的中間表示式不會用來做後續工作了。

當時看完之後我才恍然大悟，爾後才終於看懂 shecc 的前端處理。例如說產生中間表示式的方式，可以先聚焦在 add_insn() 函式的使用即可。

因為前面的遭遇，就讓我想知道「shecc 的發展歷史」，這個歷史並不是說要將 2019 年到現今一直以來的更改通通逐一說明，而是說有一些關鍵的變動，或許今年的開發紀錄可以論述，這樣其他開發者在閱讀部份原始程式碼的時候，就可以減少類似我前面描述的那個遭遇。

不過什麼修改是「關鍵」的，或許是一個要討論的點。

小結

因為 shecc 已發展了約 5 ~ 6 年的時間，對於想學編譯器的人來說，可以當作一個學習的案例，不過以我目前發現到的事情來說，如果今年的開發紀錄可以更加描述我前面提及的那些點，相信可以讓 shecc 的閱讀素材，完整性更加提昇，吸引更多人來閱讀並投入編譯器研究。

Linux 核心專題: 多核 RISC-V 模擬和 Linux 驗證

疑問 1

SBI HSM Extension 一節有提到 hart 在 HSM 的管理中會有 7 種狀態，其中 STOP_PENDING 、 START_PENDING 、 SUSPEND_PENDING 、 RESUME_PENDING 等狀態，可以不用在 semu 模擬

這樣的描述對我來說還是有點模糊空間，這樣的說明似乎也可以解讀成「要模擬還是可以進行模擬」，如果這裡可以更加細說不用模擬的原因，或許會更好

補充 1

在 Device tree 一節有說明到 Device tree 存在的原因，並且引用 Bootlin 公司製作的簡報〈Device Tree for Dummies〉，來輔助說明如何撰寫並定義 Device tree

前陣子在 GitHub 上瀏覽開源專案時，有看到 devicetree-org/devicetree-specification（可簡稱為 DTSpec）這個儲存庫，想學習 Device tree ，可以作為一個參考材料之一。

DTSpec 目前有提供 v0.4 版的 PDF 文件可以直接下載，本質上就是一本電子書，對於 Device tree 的相關介紹及說明很詳盡，對比簡報形式的素材（簡報通常僅以條列式文字解說），相信若能提供這份素材在開發紀錄中，可以讓大家更好閱讀並學習 Device tree。