C語言程式設計閒聊（0）程式開發環境－Mac下開發環境閒聊

泛UNIX環境（http://zh.wikipedia.org/wiki/%E7%B1%BBUnix%E7%B3%BB%E7%BB%9F）指的是一定程度上遵從POSIX規範的作業系統，這些作業系統多提供POSIX API支援，並且提供完善的CLI介面，對程式設計師來說，由於其完善的CLI介面能提供便於script file撰寫、套件管理工具整理與更新、以及較完善的檔案系統，故受到相當比例的軟體工程師喜愛。

我自己平常是Mac和Linux切換著用，他們兩個都是UNIX環境，先介紹Mac下的開發環境，下一篇再來談Linux下（以及工作站下）的開發環境。




在Mac OS X下開發C語言

通常不會遇到有課程助教要求學生用這平台啦XD  所以通常會用這平台寫程式的都是自己本身就在用。在早年我買第一台Mac的時候，那年代用Mac的人基本上都是藝術相關工作者與程式相關工作者，也因此通常用Mac寫程式的人自己會有辦法找到怎麼撰寫程式。但因為現在Mac氾濫，不少潮哥潮姊也會買來用，所以其實現在用Mac的人未必會有自己找怎麼寫程式的習慣。

不過還好的是，因為Mac本身的GUI夠力，所以對初學者來說，如果你要純用GUI來寫程式是絕對可以的，而且Apple官方提供的XCode也是一個相當完善的IDE，要用XCode來開發也是可以。

1. IDE
• Code::Block
• 跟Windows版一樣，基本上設定都一樣，所以直接灌好拿來用就好了XD
• 不過我當助教的那一年，不知道為什麼Code::Block for mac灌起來就crash，所以去年其實我不建議在mac用Code::Block
• 但今年灌起來運作蠻正常的，目前使用起來還頗為正常，今年使用mac的人應該可以淡定地用Code::Block XD
• （不過剛剛聽說好像有人在10.8上用會有問題？）
• Code::Block使用心得[待補]
• XCode
• Apple官方提供的IDE
• 開發Mac app與iOS app（使用ObjC與其Cocoa API時）基本上一定得用
• 也可以拿來開發C語言程式
• 因為XCode很肥所以我之前基本上沒有拿它來當做C語言的開發環境，過去的版本在網路上看到的評價也是覺得不太適合拿來開發C語言（比較適合當ObjC的開發平台）
• 但是最新的版本我前幾天用了一下，雖然還是很大，但XCode的完整性確實讓人驚嘆，也蠻符合我對現代IDE應該要有的想像，之後應該會補一篇XCode使用教學文來
• XCode使用心得文[待補]
2. 編輯器+編譯器

由於Mac是UNIX，所以他的CLI其實經過調教後還蠻好用的，也因此我自己常用的模式大多是採用「編輯器＋編譯器」的方式於Mac上撰寫C語言程式。但其實在編輯器的部份，未必一定要用指令模式的編輯器，也可使用如Sublime等GUI的編輯器。殆要編譯的時候，再開Command line來編譯即可，以下介紹我在mac上有用過的editor和compiler

• 編輯器
• Sublime
• 付費軟體（但有免費版）
• 跨平台軟體（Windows/Mac/Linux）
• 有相當好的自動排版與自動補完功能
• 有相當好的套件管理與插件功能
• 插件自由度高，可自行修改，可把自動補完需要補的內容依照自己的需求修正
• 他沒有列印功能（我也很想知道他為什麼不做...）
• （參：我的Sublime使用經驗[待補]）
• 在視窗環境上是相當不錯的開發環境，我除了用vim以外，另外的開發環境就是用Sublime
• vim
• vim是源自泛UNIX平台下的編輯器，主要操控以鍵盤操控為主
• 在Mac的CLI的shell可以直接把vim叫出來，也可以裝MacVim，讓你能從「應用程式」裡面叫他出來
• 本體輕巧，可自由加裝套件，加裝套件之後可擁有相當強大的變數自動補完能力（參：如何改裝vim成為C語言編譯環境[待補]）
• 學習門檻高
• 雖然一開始看到別人用vim會覺得很奇怪為什麼有滑鼠不用一直用鍵盤操控，但是對vim派來說，因為寫程式本身就是大量使用鍵盤的工作，如果中間為了操控而切換到滑鼠，反而會中斷你的思維，而且手勢很不順。
• 所以對vim派的人來說，大部分寫程式的時間手都不會離開鍵盤，因為包含打字和環境操控都是用鍵盤處理，所以速度會快很多
• 配上ctags和cscope之後，拿來trace大型程式碼很好用
• 編譯器 
• gcc
• 現在mac上自帶的gcc，是gcc-4.2前端＋LLVM後端，而這樣的作法惹毛了gcc社群，故gcc於4.3後更改授權為GPLv3，因此目前mac上自帶的gcc版本只停留在gcc-4.2。當然你也可以透過MacPort或homebrew等CLI下套件管理程式去取得GNU-gcc的新版
• LLVM
• Apple之所以不再升級mac裡的gcc，除了GPLv3的議題之外，還有另外一個原因是Apple本身是LLVM最大的支持者
• 尤其配上了Clang前端之後，Clang-LLVM在編譯C/C++/ObjC上並不輸給gcc
• 而且Clang的前端的強大程度比gcc好太多了，gcc吐error message不知道是給誰看的，但clang吐的error message是人類看的懂的！
• 多想兩分鐘，你可以改用LLVM！

C語言程式設計閒聊（0）程式開發環境－Windows下開發環境閒聊

Windows-based environment

有鑑於大部分學生都只會用Windows-based的開發環境，所以通常助教會介紹Windows的開發環境。我是覺得基於容易上手這件事情教Windows下的開發環境也不是不行啦，但是某些老師限定使用Windows VC開發環境、甚至使用Windows only（或甚至是VC only）的一些函式庫其實是不太妥的（甚至是DOS時代的conio.h），當附錄談談就算了，如果在教學時使用這些限定OS的函式，會導致學生後來使用其他編譯器和OS時會有很大的問題，也搞不清楚哪些函式是windows限定，我個人並不覺得這是一個好的教學方式...。當然在我自己擔任助教的課程當中，我們和我老闆的共識都是，要都盡量避免此種狀況的發生，盡量不談OS-dependent的東西。

由於Windows下的CLI(Command Line Interface)功能十分的薄弱，CLI還停留在MS-DOS年代的能力，雖然後來MS有增加了PowerShell，但是似乎也仍是罕有人用，通常需要加上如Cygwin之類的平台來模擬「類UNIX環境」才會有比較好的CLI介面。

也因此，大多數人在討論Windows開發環境時，大多數時候談的是圖形化的IDE（整合式開發環境），但其實配合Cygwin的話，亦可使用編輯器+編譯器的開發方式，我自己擔任助教期間也遇過有人使用此種開發環境，其實也是不錯啦。但如果問我看法的話，我會覺得如果習慣CLI的人，直接來投奔我們泛UNIX OS就好啦XD

下面就我自己曾經接觸過或看過有人使用過的環境給一點個人的心得評價

1. IDE
• Code::Block
• 這是我目前推薦在Windows上使用的IDE之一，他是GPLv3授權的開源軟體，而且是跨平台的，在Windows/Mac/Linux上都可使用，作為教學上推廣給學生使用的IDE，教一個跨平台的IDE（而且計中電腦自帶Code::Block）當然是比較推薦的
• 比較麻煩的是他的變數、函式自動補完相較起其他IDE比較起來比較弱，如果可以的話我自己會建議在撰寫程式碼的時候使用Sublime等自動補完很強大的編輯器，再透過Code::Block來編譯和除錯
• Code::Block使用心得文[待補]
• Dev C++
• Dev C++其實是一個令人又愛又恨的IDE，他在2006年我剛念大學的時候很潮，大家「私底下」（等一下會解釋為什麼是私底下XD）都用Dev C++，但是他2005年之後就都沒有更新，版本一直停留在4.9.9.2，裡面編譯器則是停留在gcc 3.4.2，如此舊的gcc版本會使得許多新的編譯器功能無法支援。
  此外，許多當代IDE必備的功能：自動補完、自動排版、除錯工具整合、監控工具整合等等，不是殘缺不全就是沒有支援，在八年（遺毒）沒有更新的狀況之下，近年來其實不太推薦使用Dev C++，甚至採用Dev C++還會成為網路戰文的戰點（詳參：李大師您多久沒寫程式了 ? 一百個你不應該繼續用Dev C++的理由 ）
• 但是，自2011年開始，有位神手Orwell大大（詳參：Orwell Dev-C++）將舊有的Dev C++自行fork出一條branch，將內部的gcc、gdb升級，並加上了當代IDE或程式編輯器必備的自動補完與自動排版功能，並且一路到今年2013都還有在維護，故其實我個人蠻推薦Orwell Dev-C++的，去年我也有推薦學生使用。
• 但是因為歷史的包袱，許多人仍然會不小心載到舊的Dev-C++ 4.9.9.2，而非新的Orwell Dev-C++，故實際Demo時仍會出現一些遠古的問題...
• 總而言之，如果你是自己要使用的話，Orwell Dev-C++是個蠻不錯的現代IDE，但是如果你是助教要教學用的話，你可能會遇到有學生還是載舊的Dev C++過來問你問題......
• DevC++使用心得文[待補]
• Visual Studio
• VS其實我有用過，但是其實我除非萬不得已不然不會使用他，原因是他綁太多Windows only的東西，而且雖然功能上相當的完善，絕對符合我評斷現代IDE的標準，但是因為我自己大多數開發的環境不是在Windows上，故我沒有花太多時間研究VS。
• 作為初學時使用的開發平台的話，因為他基本上都要使用專案形式開啟，故在能編譯出第一個程式所需要調教的設定比Code::Block和Orwell Dev-C++比較起來多得很多，初學者用起來會比較辛苦。但作為一個IDE的完整性來說，卻是比Code::Block和Orwell Dev-C++的完整，我也不會說他不好啦，只是我自己不太愛就是了
• Turbo C 
• 這個年輕人應該都沒聽過才對，因為他是DOS時代的IDE（使用影片參考：http://www.youtube.com/watch?v=TfvvpS1eIMQ）
• 但是我大一時候老師卻是叫我們用這個= =，我是2006年修的課不是1996年耶
• 所以才會有大家私底下是用Dev C++之說，因為上課時候官方是說用Turbo C
• 雖然說開發環境只是工具，其實用的順手都沒差，但是Turbo C不僅沒有當代IDE該有的自動補完、自動排版、當代除錯器、監控器，更大的問題是，他必須要到DOS模式下開啟，並且是WTF的16位元編譯環境！！！
• 也就是說，我大一記得的int大小是32767~－32768，這個是16-bit OS下的值，在現在主流的32-bit上早就不是這個範圍了，現在連iPhone都上64bit了，是有多少人在16-bit的OS下開發啦（掀桌）
• 然後聽說上了Win7之後，因為把DOS模擬器拿掉了，據說Turbo C變得更難裝起來了（茶），大家可以與時俱進嗎...... 該淘汰的東西就該淘汰了～
2. 編輯器+編譯器
• 編輯器
• 記事本（Notepad）
• 除非走投無路，不然別用。
• 他連幫程式碼關鍵字上色都不行，這就別拿出來丟人現眼了吧...
• Notepad++
• 開源自由軟體
• 看Code的時候很好用，因為他會幫程式碼上色
• 他可以列印XD（Sublime不知道為什麼沒有列印功能）
• 有自動排版功能
• 唯一的問題是似乎沒有自動補完
• UltraEdit
• 付費軟體
• 在沒有Notepad++以前，他是看程式碼時的好幫手
• 現在在Notepad++出來後，基本上較少看到有人在用（但我以前年輕時候用過）
• Sublime
• 付費軟體（但有免費版）
• 跨平台軟體（Windows/Mac/Linux）
• 有相當好的自動排版與自動補完功能
• 有相當好的套件管理與插件功能
• 插件自由度高，可自行修改，可把自動補完需要補的內容依照自己的需求修正
• 他沒有列印功能（我也很想知道他為什麼不做...）
• （參：我的Sublime使用經驗[待補]）
• 在視窗環境上是相當不錯的開發環境，我除了用vim以外，另外的開發環境就是用Sublime
• vim
• vim是源自泛UNIX平台下的編輯器，主要操控以鍵盤操控為主
• 在Windows上可以用gVim，亦可以用Cygwin裡面的vim
• 本體輕巧，可自由加裝套件，加裝套件之後可擁有相當強大的變數自動補完能力（參：如何改裝vim成為C語言編譯環境[待補]）
• 學習門檻高
• 雖然一開始看到別人用vim會覺得很奇怪為什麼有滑鼠不用一直用鍵盤操控，但是對vim派來說，因為寫程式本身就是大量使用鍵盤的工作，如果中間為了操控而切換到滑鼠，反而會中斷你的思維，而且手勢很不順。
• 所以對vim派的人來說，大部分寫程式的時間手都不會離開鍵盤，因為包含打字和環境操控都是用鍵盤處理，所以速度會快很多
• 一直用鍵盤下指令看起來很威XD
• 會發現你和你的前輩都是同樣用vim寫程式會覺得很溫馨
• 如果你在Windows下vim用熟了之後就可以準備投靠Mac/Linux等泛UNIX環境了
• emacs
• 我沒用過他（因為我是vim派XD），但我當助教的時候有學生在用，而且是Cygwin配emacs
• 雖然我是vim派，但是我覺得用emacs或vim都ok啊，這兩者在使用上我覺得沒有什麼真正影響程式開發環境的部份
• 只是聽說學習門檻也不比vim低就是了 

• 編譯器 
• gcc
• 裝Cygwin的時候通常會自帶，基本上對入門的來說只要知道編譯指令怎麼下、如何執行你寫的檔案就好了
• 只可惜他現在是GPLv3
• LLVM
• 其實我沒在Windows上用過LLVM  orz
• 我怎麼記得LLVM到Windows上的porting好像很困難，好像還在弄的樣子

接下來的文章，將談在其他泛UNIX平台上的開發環境，因為我自己現在幾乎沒有使用Windows，所以接下來的文章才是我自己事實上習慣使用的環境。

C語言程式設計閒聊（0）程式開發環境閒聊－總論

由於去年曾經當過大一程設助教，藉此重新審視了複習了一次C語言的教學流程，和自己當初學習的狀況不同的是，重新以一個相對有經驗的 Programmer的觀點重新審視會有著許多不同的看法，去年時就想整理出來給自己做個記錄也分享給其他人，但總因為時間分配上的關係無法如願。所以今 年雖然不再是助教，但想根據今年程設上課的進度來補充自己對該部分的看法。

這一系列文章基本上都是我個人的閒聊，不代表任何課程的官方看法。

通常在一開始教學程式設計時，開發環境的建立是首要的課題，尤其剛從高中畢業且從未接觸過程式開發的新手來說，這個部分會是入門的第一個小門檻，而實際會遇到的狀況其實會根據授課教師與助教的Demo要求會有各種不同可能會遇到的小困難，我們以下分別討論。

要談程式開發環境，首先必須先釐清撰寫程式本身到底是在做什麼？

首先，在電腦上運行的是machine code，是由01組成的二進位編碼，非常人所能理解。而我們在撰寫程式時使用的是較接近人類自然語言的程式語言，故撰寫程式這件事情就是：「把你的運算邏輯以程式語言撰寫出來」，並把它存成一個檔案（例如：test.c）。但是這個test.c並不是真正的machine code，而從.c檔變成真正machine code的過程就是編譯流程，在經過編譯流程之後就會變成真正電腦看的懂得可執行檔（以Windows系統為例，他就會變成test.exe）

所以，從你寫一個HelloWorld.c，到你真的到螢幕上看到他的執行結果。需要「撰寫程式碼」與「編譯」的兩道步驟（編譯的部份可以細分成許多步，但對初學者來說只需要知道是透過「編譯」的行為，將「程式碼」（test.c）轉換成「可執行檔」

通常程式設計師在開發的時候分為兩派，一派是透過一套整合性的開發環境（IDE，Integrated Development Environment）來把程式碼編輯和編譯流程整合在一個環境裡，這樣的好處是要寫程式的時候只要開這套軟體就可能開始寫了。
另外一派則是透過專門給程式設計師用的文字編輯器編輯程式碼，並將編輯好的程式碼存成test.c，再自行選用編譯器來將其編譯成可執行檔。

我個人的使用經驗，其實「IDE」和「編輯器＋編譯器」在一般使用上各有優劣，IDE對比較上層的開發比較有利，而「編輯器＋編譯器」的開發方式對底層工程師要做細部調教比較方便。

以我自己現在開發C語言程式的習慣，除非在撰寫與OS提供的API高度相依的（例如winsuck winsock） 之類的狀況不得不用該OS自帶的IDE外，其實大多數開發的時候是在純文字編輯器上先撰寫好程式，再自行透過編譯器編譯後，透過自己撰寫的 Makefile去產生出可執行檔。會這樣使用的原因主要是IDE所附之編譯環境，IDE不時就會自己增加或修改一些編譯參數的設定，甚至自己產生出一些 有問題的Makefile，對我來說與其去花時間使用IDE所產出的bug，還不如自己掌握整個編譯流程，以便根據自己的需求做延伸。

不 過對於剛入門的新手來說，因IDE而起的bug並不多，使用IDE來撰寫對大部分人的入門門檻較低，也因此許多程設課程會使用IDE做開發。現代IDE可 以提供的功能相當的多，包含關鍵字自動補完、除錯工具整合、即時監控測量程式運行時期情形等，其實有些時候使用IDE也是不錯的選擇，尤其是利用 Java、ObjC、C#等高階語言配合OS提供的API開發視窗程式設計時，幾乎都是使用IDE來開發的。但純就C語言來說，IDE可以利用範圍比較 少，故有些老師會不建議使用IDE，但對我個人而言，只要你能自己解決因使用IDE而產生的bug的話，那使用IDE並無不妥。

不論「IDE」或是「編輯器＋編譯器」的使用，我個人認為都需要有下列幾點需要注意的

• 程式編輯
• 程式碼上色
• 這真的很重要，不然辨識度會超低的
• 自動排版
• 首先，程式碼排版真的很重要，不然你連自己的程式碼都看不懂
• 但是有時候臨時要加一些東西，你又不想一行行縮排的時候
• 這時候，身為一個現代良好的編輯器，他要有自動幫你縮排的功能才行
• 自動補完
• 自動補完指的有兩個部分，其一是指把先前自己宣告或函式庫定義的變數、函式名稱自動補完。
• 其二是指只需輸入極少的關鍵字，就可將常用的Code Piece直接補完的功能。
• 這兩種自動補完對現代的程式設計師相當的重要，尤其當你開發大型程式時，現代主流的命名方式是希望你以變數、函式名稱就可以代表其含意，而盡量降低註解的撰寫。在這樣的思維下，變數與函式名稱不免會命名的很長，因此選用一個能夠幫你自動補完的編輯器是相當重要的
• 或開發較高階的語言（如Java、ObjC、C#）的時候，許多系統提供的API等名字你不可能全記得，所以非常需要自動補完的功能來輔助
• 編譯與除錯（在IDE時此部份包含於IDE中，若是選用編輯器+編譯器的作法則可自行選用適合的Compiler和Debugger配著用）
• 編譯器選用 
• 你可以自行選用你要的編譯器與其版本（這很重要，因為以後你有可能遇到在某個版本以前才編的過的程式碼Orz）
• 可以讓你自行下參數直接餵給Compiler
• 除錯器整合
• 寫程式有bug很常見，但是要如何debug就是一門藝術
• 故IDE必須要提供方便的方式來整合除錯器讓你除錯
• 沒辦法讓你好好除錯的IDE就果斷扔了他吧！

尤其是近年來軟體開發工具的發展，比較先進的開發工具上述幾點都已經做的不錯（well，至少對我來說我覺得還不錯啦），故若能選用符合現代強大的開發工具，對你之後的開發會有相當的助益

接下來，會對各種開發環境會需要知道的事做介紹，以及提供自己對該環境的個人評價

Virtualization相關Conference

Red: A class top conf.
Orange: B class top conf.
Green: Other conf.

Virtualization

•  VEE - International Conference on Virtual Execution Environments

OS

• OSDI - Operating Systems Design and Implementation
• SOSP - Symposium on Operating Systems Principles
• USENIX - USENIX Technical Conference
• RTSS - IEEE Real-Time Systems Symposium
• USITS -- USENIX Symposium on Internet Technologies and Systems 
• HotOS(WWOS) - Workshop on Workstation Operating Systems
• Hybrid Systems
• CASES - Compilers, Architecture, and Synthesis for Embedded Systems
• SDSDI - Unix Symposium on Operating Systems Design and Implementation 
•  

Architecture and Compiler

• ISCA - International Symposium on Computer Architecture
• MICRO - International Symposium on Microarchitecture
• ASPLOS - Architectural Support for Programming Languages and Operating Systems
• HPCA - International Symposium on High-Performance Computer Architecture 
• PACT - International Conference on Parallel Architectures and Compilation Techniques
• CGO - Symposium on Code Generation and Optimization

Mobile and embedded system

• EMSOFT - International Workshop on Embedded Systems
• MOBICOM: ACM/IEEE Intl Conf on Mobile Computing and Networking
• MOBISYS: International Conference on Mobile Systems, Applications, and Services
• SCOPES - International Workshop on Software and Compilers for Embedded Systems
• LCTES - ACM SIGPLAN Conference on Languages, Tools, and Compilers for Embedded Systems 

參考資料： 清交資工系升等與博班點數標準

如何讓vim能自動parse出ARM的組合語言

在開發Linux kernel for ARM的時候，我們時常會使用vim來編寫程式碼，在一般以C語言撰寫的部份，vim皆能正確地對程式碼標色。但是在組合語言( Assembly language )檔案的部份，許多時候並不能對指令、參數等正確標色，實為缺憾。

但是我們發現在vim.sourceforge網站上，有人提供了armasm.vim的檔案，能夠讓vim能夠正確的對arm的組合語言標色。不過可惜的是只有Support到v5以前的指令，在v6之後的指令就只能自行修改armasm.vim檔案來支援，不過對於大多數的指令來說已經很夠用了。

其網頁於此：http://vim.sourceforge.net/scripts/script.php?script_id=888


其使用方法如下：
（註：我的使用環境是Ubuntu 11.10，VIM 7.3 for Ubuntu）

1. armasm.vim要放置的資料夾建置

   在家目錄下，建置.vim資料夾，再於.vim資料夾下建置syntax資料夾
   前述資料夾若已經存在則不需再另外建立

2. 取得並放置armasm.vim檔案

     (1) 去http://vim.sourceforge.net/scripts/download_script.php?src_id=4029 下載armasm.vim檔案

     (2) 將方才下載的armasm.vim檔案放置到~/.vim/syntax下

3. 修改家目錄下的.vimrc檔案，使vim能預設啟用armasm.vim檔案

    增加下列字串：

let asmsyntax='armasm' 
let filetype_inc='armasm'

調整好後，用vim開啟arm組合語言檔案就能正確標色

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.

Alignment & Padding (English)

In order to prevent alignment exception, compiler will pad some empty data into memory to let it fit the alignment restriction.
Here is an example in C:

If we declare a structure like this:

struct align{
   char a;
   int b;
   short int c;
};

We will consider that it will use 7 bytes. However, because it has to prevent alignment exception,compiler will add some padding to let it fit 32-bit (i.e. 4 bytes). It may consider like this:

struct align{
   char a;
   char padding_0[3]; // add by compiler, programmer cannot use   
 
   int b;
   short int c;
   char padding_1[2]; // add by compiler, programmer cannot use   
};

Its memory allocation will look like this:
(放圖)

It is obvious to see that padding will waste lots of memory space. As a result, in order to save memory space, sometimes compiler also provide some pragma to let programmer to add in their code, and compiler can use these pragma to let compiler reallocate the memory allocation of this structure.

Here is an example:

#pragma pack(push)
#pragma pack(4)
        struct align
        {
                char a; //1 byte
                int b;  //4 bytes
                short int c;  //2bytes
        };
#pragma pack(pop)

It will let compiler to reallocate its memory allocation and use memory more efficiently.

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.

Ref: http://en.wikipedia.org/wiki/Data_structure_alignment

About me

Junior System Software Programmer

M.S. in CS
B.S. in EE

In EECS area

Major research interest: Virtualization, Kernel
Minor research interest: Computer Architecture, Compiler, Other system software
More minor research interest: Digital Signal Process
Just for fun: Probability, Electromagnetism

Familiar develop environment:
Processor: ARM, x86, TI-C64xx;
OS: Linux, Mac OS X;
Compiler: GCC, Clang-LLVM

Preferred Software License: BSD License
Preferred Kernel: XNU ( Darwin Kernel )
Preferred Compiler: LLVM


於EECS領域研究興趣：
主要研究作業系統核心、虛擬化技術。對於計算機架構與其他系統軟體亦有相當的研究興趣。因過去大學時的經驗，對DSP、機率、電磁相關領域的知識，亦會作為業外新知來吸收。

熟悉的開發平台與環境：
在處理器架構上，主要對ARM有相對較高的熟悉，對x86、TI-C64xx系列亦有些微了解。在作業系統環境上，主要開發對象為Linux，主要使用環境為Mac OS X與Ubuntu。在編譯器環境上，傳統上使用GCC，最近亦對LLVM有興趣接觸與使用。