# 2025q1 Homework1 (ideas)
contributed by <`DrXiao`>

---
參照去年的期末專題列表後，目前選定以下專題來閱讀並撰寫我的疑惑與見解
* Linux 核心專題: shecc
* Linux 核心專題: 多核 RISC-V 模擬和 Linux 驗證

## Linux 核心專題: shecc
其他相關素材或資料
* [2020q3 專題: 可自我編譯的 C 編譯器](https://hackmd.io/@sysprog/HkqE5DKqP)
* [從零開始建構 C 語言最佳化編譯器](https://docs.google.com/presentation/d/1RoSFZQdy4dqEYR9LRI5ShIFA_LMMlCmJImKIN3V_ry0)
* [2024 COSCUP 發表錄影](https://youtu.be/eSDWZJhpU30?t=24023)
### 疑問 1：shecc 的目標或限制
shecc 起初是為了教學為而建立的編譯器專案，自 2019 年便持續發展至今，老師也會在實體課堂、線上授課或是其他公開場合講解 shecc 時，數次提起 shecc 的設計理念。

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

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

---
以第一點來說，雖然我知道 shecc 可以自我編譯，但我從過往的開發紀錄中沒有閱讀到：
1. 為什麼要讓編譯器可以自己編譯自己？
2. 這件事情可以帶來什麼好處？
3. 與不能自我編譯的編譯器會有什麼樣具體的差別？
4. 要讓編譯器可以自我編譯，大概哪些什麼地方要特別花功夫設計並實作？

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

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

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

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

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

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

但反過來說，其實 shecc 也是有部份環節是沒有做到的，例如：
* 抽象語法樹（Abstract Syntax Tree）
* 與硬體架構有關的最佳化

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

---

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

### 疑問 2：shecc 的發展歷史
這點是去年有了 GitHub [issue#174](https://github.com/sysprog21/shecc/issues/174#issuecomment-2551086150) 的討論，我才有的疑問。

上面給定的超連結，是當時候某位開發者利用 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](https://hackmd.io/@sysprog/HyQ9UQ2E0#SBI-HSM-Extension) 一節有提到 hart 在 HSM 的管理中會有 7 種狀態，其中 `STOP_PENDING` 、 `START_PENDING` 、 `SUSPEND_PENDING` 、 `RESUME_PENDING` 等狀態，**可以不用在 semu 模擬**

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

### 補充 1
在 [Device tree](https://hackmd.io/@sysprog/HyQ9UQ2E0#Device-tree) 一節有說明到 Device tree 存在的原因，並且引用 Bootlin 公司製作的簡報 〈Device Tree for Dummies〉，來輔助說明如何撰寫並定義 Device tree

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

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