C

故事是這樣子的， 很早以前我寫過一篇介紹 python ctypes 的文章，已經是 7 年前的文章了， 大約在去年左右，曾經發現一個生猛的用法但那時沒記下來，最近又用到了結果又要花時間找設定，這篇就再次記錄一下。

...

故事是這樣子的，很早以前大概 2014/2015 的時候，就曾經因為傳說中的 jserv 大大的關係，聽聞傳說中的 FreeRTOS，然後也有不深入地小玩了一下。
最近又因為到前公司戀戀科技的專案，竟然又接觸到（已經被 Amazon 收購的） FreeRTOS ，花了點時間把 FreeRTOS 移植到某個新的 ARM 平台， 在移植的時候也稍微仔細的 trace 了 FreeRTOS 的程式碼，順便就寫了點筆記，整理一下貼上來。

...

故事是這樣子的，小弟在公司工作內容，要維護公司產品核心的engine，要維護當然會需要把程式碼從版本控制裡簽出來， 修改、編譯後測試修正有沒有問題，而編譯一直以來都非常花時間。
本文介紹的 ccache 是 compiler cache 的簡稱，會在編譯時存下檔案內容的 hash 與編譯結果，在未來如果有相同的檔案要編譯的時候，就不用再次呼叫 gcc/g++ 進行耗時的編譯，只要把存下的 object 檔從 cache 裡面抓出來就行了。

...

故事是這個樣子的，寫 C/C++ 必定會遇到的就是每個檔案開頭的 #include，這可以帶入其他人寫好的程式碼，最後連結的時候再連結函式庫完成整個程式。
不過大家都知道，程式不是寫完就算了，是會長大跟更新，這時候 include 就會慢慢過時，可能本來需要的 include 現在不需要了，但通常我們不會意識到這點。
另外，在一些 project 上，會出現所謂的組合的標頭檔，例如 Qt 會有 QtGui 標頭檔，內含幾乎所有 Qt 元件的標頭， 不管需要什麼 Qt Widget 只要有 QtGui 都能搞定，但問題就是 include 一個標頭檔會帶進標頭檔裡所有程式碼，巨大的標頭檔如 QtGui 會顯著拖慢編譯速度； 如果只是一兩個檔案當然沒什麼，但在大 project 上，例如我之前改的 qucs ， 我把裡面的 QtGui 全部換成專屬的 Qt Widget 之後，單核心編譯時間從原本的344秒加速到245秒，提速 29 %。

...

故事是這樣子的，小弟第一次學寫 code 的時候，是在大一修計算機程式（嚴格來說是高三下學期上了幾個小時的 C，不過那實在稱不上是"學"）的時候，第一個使用編輯器是破舊破舊的 Dev C++ ，我打這篇的時候差點都忘了它叫 Dev C++ 了。
當然那時候的功力跟現在實在是天差地遠，淨寫一些垃圾，啊雖然現在也是淨寫一堆垃圾…。
總之後來應該是大二，被同學們拉去演算法課上當砲灰，第一次接觸了工作站 + vim，從那時候把 Dev C++ 給丟了跳槽到 vim，就一直用到現在， 之中當然也會用一下其他的編輯器，像是改 windows 的 .NET 程式用到 Visual Studio，但大體還是以 vim 為主力，算算也是超過 10 年的 vimer 了。

不過這兩三年在工作上、日常 project 上面，多多少少都見識到 vim 的不足之處，例如

• 新語言（主要是 rust）支援不足
• 跟編譯除錯工具整合不佳
• 跟 GUI 整合不佳
• 跟 Git 整合不佳要另外開終端機跟 gitg
• 自動格式化/排版操作麻煩而且通常排不好

正好此時 Microsoft 回心轉意擁抱開源，推出了 vscode，隔壁棚的 emacs 有大神跳槽鬧得風風雨雨 ， 台灣 CUDA 第一把交椅強者我同學 JJL 也跳槽 vscode 惹還來傳教。

...

故事是這樣子的，之前小弟發下豪語想用 Rust PEG 寫一個 C Parser，然後…就沒有然後了。
好啦當然不是，不然就不會有這篇文了。

總之最近經過一陣猛烈的攪動之後，我的 parser 能處理的文法終於接近當年在學校修 compiler 的時候所要求的 B language 了， 說來慚愧，當年寫 compiler 作業的時候 parser 只是裡面一個作業，要在 2-3 週裡面寫完的，結果現在搞半天寫不出個毛， 果然上班跟上學還是不一樣，在學校可以全心全意投入寫 code ，週末的時候還可以熬個夜把作業寫出來；現在上班白天要改公司的 code ，晚上回家累個半死不想寫 code 只想開卡車(欸。

本篇講到的程式碼目前還沒推到遠端上，相關的程式碼可以參考：
AST 的資料結構：cast
型別的資料結構：ctype
既然現在可以處理比較複雜的文法了，再來要做什麼？

...

故事是這樣子的，小弟在公司裡面，主要是負責維護一個沒人在用的產品，遠觀來說這個產品滿複雜的，內建兩種不同的演算法實作，為的是要應對不同的狀況，有些狀況用第一種演算法比較快，有些用第二種。
那故事是這樣子的，我們的程式裡面有一個函式會在每筆資料結束之後，用上筆資料的結果來判斷下一次要選哪個演算法， 問題是這個函式目前是直接寫在整個引擎的 C code 裡面，於是如果想要改變一下判斷的標準……sorry 重新 build， 雖然公司弄了套分散編譯可以編很快但還是要幾分鐘。
上星期自己試了一下，成功把 Lua 編到公司的 code 裡面，就能把判斷邏輯寫在 Lua script 裡面，要改判斷標準只要改 Lua 就可以了； 我一般聽到會這樣用的是遊戲公司，因為遊戲一樣涉及大量的邏輯判斷，例如血要扣多少之類的，而遊戲又會大量的去變動這些參數， 使得彈性變得非常重要，總不能要改參數就把整個遊戲引擎全部重建構一次…… 說是這麼說我也不曾證實哪家公司真的這麼做就是，如果我的讀者真的是這樣搞的麻煩留個言讓我知道一下。

...

最近費式數列實在有點紅，讓小弟忍不住也來玩一下。

費式數列給一個初學程式的人都能寫得出來，例如早年我忘了哪位大大在推坑我 python 的時候，就寫了個只要 4 行列出費氏數列的 python 程式，一方面展現 python 在大數運算上的實力，一方面展視了它的簡潔，像是 a , b = a+b, a 這種寫法。

...

自從去年十月把 nixie tube clock 完工之後，好像都在耍廢之類的，結果 11/12 月兩個月都沒有發文， 其實這兩個月裡面，有的時間都在改之前寫的 C parser ， 其實整體完成度愈來愈高了，今天發個文來整理一下到底做了啥。
這次做了幾個改變，主要的修正就是加上 expression, declaration, statment 的處理，也學到不少東西，這裡一一列一下：

...

故事是這樣子的，之前我們寫了一個自創的程式語言 Simple Language ， 還用了 Rust 的 pest 幫他寫了一個 PEG parser ， 雖然說它沒有支援新加入的函式等等，本來想說如果年底的 MOPCON 投稿上的話就把它實做完，結果沒上，看來是天意要我不要完成它（欸

總而言之，受到傳說中的 jserv 大神的感召，就想說來寫一個複雜一點的，寫個 C language 的 PEG parser 如何？ 然後我就跳坑了，跳了才發現此坑深不見底，現在應該才掉到六分之一深界一層吧 QQQQ。

...