c

故事是這樣子的，很早以前大概 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。

最近工作上大量使用到 gdb，想說來整理一下一些常用的 gdb 使用方式，以及對應的場景；當然，這絕對不是 gdb 完整的功能介紹，只是目前我遇到比較多的使用方式而已。