筆記整理 FreeRTOS Context Switch

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

...

使用 ccache 加速編譯

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

...

使用 iwyu 幫忙整理 include 檔案

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

...

 October 31, 2020 |    c , cpp  |    c , cpp  | 3 min  |  YodaLee

第一次跳槽 vscode 就上手

故事是這樣子的,小弟第一次學寫 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 呼叫 Lua 函式

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

...

 September 8, 2019 |    c  |    c , lua  | 1 min  |  YodaLee

關於費式數列的那些事

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

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

...

 February 12, 2019 |    comment  |    c , python  | 2 min  |  YodaLee

用 PEG 寫一個 C parser 續

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

...

用 PEG 寫一個 C parser

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

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

...

實用的gdb 指令

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

...