上次我們發佈 rrxv6 的文章，已經是八月的事情了，大家可能以為我已經棄更了？ 其實這個小弟也有在認真反省，在我停更 rrxv6 這段期間剛好看到傳說中的 jserv 大神貼文：

到底高等教育出了什麼問題？為何很大比例的電機資訊畢業生，沒辦法堅持把事情做好？
思索九年，我想自己理解部分的原因：扎實地做事難以獲得短期的讚揚，而台灣許多人無法等到長期效益落實的那刻……。

想說靠北這不就是在說我嗎QQ，一直以來都沒把事情做好，像 ruGameboy 最後就被我棄更了，現在變成十八般武藝樣樣稀鬆只能混口飯吃。

...

書名	戰爭的滋味：為食物而戰，重整國際秩序的第二次世界大戰
原書名	Taste of War: World War II and the Battle for Food
作者	Lizzie Collingham
譯者	張馨方
出版商	麥田出版
出版日	2021-01-28
ISBN	9789863448457

...

終於來到我隱藏已久的終極目標了。 沒錯，其實我在拿到這片 FPGA，在想要做什麼的時候，經過一天得到的答案就是這個：Nand2Tetris ， 用 FPGA 真的把這顆 CPU 給做出來，前面什麼 UART、HDMI、BRAM 都不過是前菜罷了，實際上我在下很大一盤棋。
當然，因為我們用的是 verilog 的關係，我們不會真的從 nand gate 開始往上堆，而是用 verilog 內建的運算來實作， 所以 nand2tetris 第一、二章用 nand 弄出邏輯閘和加法器的部分就跳過，直接從 ALU 開始。

...

這次的更新比較久一點，故事是這樣子的，在試完 HDMI 之後，我花了一點時間在試著連 FPGA 版上有實體 chip 的其他裝置， 包括：SDRAM、Flash 跟 SDcard。問題是這幾個都沒那麼好連，特別是沒有 LA 的狀況下根本就是瞎子摸象， 只能用 verilator 跑跑波型，波型對了放上去不會動你也不知道是什麼問題。

...

上回我們實作了 UART 的輸入輸出，這回就來挑戰板子上有附的另一個介面：HDMI，這個實作出來我們就有影像輸出可以用了呢。
不過因為 HDMI 的難度比起來上升了一個層次，這次我是直接用 icesugar-pro 的範例程式碼 改寫， TMDS 的部分則有參考網路上的 encoder 。

...

上一章我們打通了 FPGA 的開源工具鏈，接下來我們就能測試一下 icesugar-pro 有的介面， 首先實作 FPGA 還是需要有輸入輸出，否則也只是弄出一個無法互動的程式，而最簡單的輸出入介面，就當屬 UART 了。
icesugar-pro 的 github 上，也附上了一個 UART 的範例 ， 會不斷對你的電腦輸出 “0” 到 “9”（然後這段 code 還有 bug XD），這篇我們就來寫一個有 tx, rx 的 UART 模組吧。

...

故事是這樣子的，今年的 COSCUP 投了一個 System Software 的 session ， 然後該議程軌的主持人自行提供了投稿獎勵，以下 Facebook 原文：

為了鼓勵各位同學投稿、以及體驗知識有價的參與感，在跟Jserv老師討論後，我們將提供兩位 有償 徵稿名額給這邊的同學。
投稿後有獲得錄取的前兩位同學，將會獲得新台幣 2,500 元的獎勵金，以及可以配製成RISC-V核心、運行Linux的FPGA開發板乙張！

獎勵金的部分我就回絕了，畢竟有薪人士拿這個錢道義上說不過去，留給比我有才的許多學生講者比較好。
不過 FPGA 我評估之後就收下了，畢竟 FPGA 難買，之前實驗室玩的 DE2 都要破萬元（然後它竟然停產了），然後有些 project 只用軟體寫實在沒 fu，一直想弄一塊 FPGA 來玩，於是就接受了 FPGA。

...

人生第二次參加 COSCUP ，上一次已經是在 2019 年的時候，當年的實體活動心得在此 ， 因為 2019-2020 太懶沒弄出什麼可以看的點子，2020 好像又因為什麼因素（八成是疫情）連實體活動都沒去， 今年也是因為疫情，整個活動直接變成線上的了。

...

故事是這樣子的，雖然在上上篇的 Context Switch 我們曾經預告過因為 static 的問題， 可能要停更一段時間，但後來沒停更，static 問題很快就用 spin 提供的 no_std Mutex 解決了。
不過，no_std Mutex 雖然解決 static 不用手爆 constructor 的問題，同時卻產生了另一個問題：stack overflow。

因為呼叫 static variable constructor 會用到 os process 的 stack，static variable size 一大，os process 的 stack 就會被吃乾抹淨。
所以問題來了，我們必須要儘可能的縮小 static variable 的尺寸，像上篇把 process 的 context 全塞在裡面是不可能的 （為了讓 code 動起來我把 process 數量降到剩 2 個），因此下一步就很清楚了，必須挑戰作業系統裡一大難題：記憶體管理。

...

故事是這樣子的，上一篇我們使用 unsafe 來操作 global variable，並用這個做到 cooperative multitask， 很不幸的這個方法是不行的，包括幾個問題：

1. 身為 Rustacean 非不得已怎麼可以用 unsafe 呢？這樣狂用 unsafe 根本離經叛道
2. 當 static 的型態複雜到一個程度的時候，這樣手爆資料型態絕不是方法，一定要使用 default 才行。

稍微搜尋一下之後，果然找到一個可行的方案，用社群提供的 crate spin ， 可以在 #[no_std] 的狀況下提供 Mutex（有關如何實作 Rust Mutex，' 可以參見這篇文章 ）

...