Sublime Text 3 + Toks modified for Tiano / EDK2 codebases

1. Get your Sublime Text 3, referred as ST3.


2. Follow the link below to add Package Control.


sublime.wbond.net/installation


The image below shows the successful result of the opreation.

3. Access "Package Control" through the sub menu shown as below.

4. Enter 'I' and select "Package Control: Install Packages", then enter "Toks".

5. Edit your Toks settings:
"Data\Packages\Toks\SublimeToks.sublime-settings" under the ST3 folder, and add these filters to your "filename_extensions":

"bat|c|cpp|h|hh|asm|asi|inc|asl|aslc|vfr|uni|dec|dsc|fdf|inf|ini|template|env|makefile"

"Data\Packages\Toks\SublimeToks.py": Line 139 under the ST3 folder.

original:

match = re.match(re.escape(self.commonprefix) + '(.+:\d+:\d+) (\S+) (\S+) (\S+) \S+', line)

modified:

match = re.match('(.+:\d+:\d+) (\S+) (\S+) (\S+) \S+', line)

6. Add your project folder into project, and save your project files

7. Press CTRL + L, CTRL+I to tag your codebase. The tag file will be at the same directory in which the project file is.

8. Read Data\Packages\Toks\README.md under the ST3 folder as a manual.

別以為你不會碰到 (2)

常常看到有人寫了一堆檔，等到要互相做連結的時候，才開始在需要用的 c 檔裡面做 extern，『要用的函數交給 extern，責任全交給編譯器』，這樣其實超危險。

要知道 c 是一個完全依賴 coder 邏輯的語言，除了 syntax 或 casting 這種低級錯誤之外，其它模陵兩可的動作，編譯器的預設立場是『我相信這是你要的結果』。

//aaa.c
int func_a (uint8_t numInput) {
  return ++numInput;
}

//bbb.c
extern int func_a(void);

int func_b (void){
  int numCatch;
  numCatch = func_a();
  printf ("holy shit %d\n", numCatch);
  return 0;
}

範例舉得很傻，但定義如下：

int* GetHash (
    int *workingBuffer, 
    char **hashArray, 
    double potential, 
    uint32_t modulus
)

還敢說不會有問題嗎？

extern 聲明參數和定義不同。這範例結果是 linker 在連結的時候不會報 error，程式執行印出來一堆從暫存器拉出來的鬼數字。

當做一個比較大型的項目，也許會拆到近萬隻源檔，這時候一些基本功就能看得出高下。

需要發佈到所有源檔裡面的函數，我會直接拖個原型在 .h，這邊就是發佈的根源，要用這隻函數，請 include header。不需要發佈的，一律上 static 鎖死在這隻檔裡，或乾脆做 inline。

第一個就是多數 compiler 抓得出錯誤，無須下額外指令，第二個就是非常好整理，畢竟用的是近 30 年的舊語言，它不是很聰明，我們就要多想想。

近期的感悟

最近在工作上發現很多奇妙的東西。OEM 板子 port 的跟 CRB 一模一樣，可是就是點不亮，GPIO 設定說是 62 隻，可是注解就寫 61~63 腳是做啥啥用的。

這次做 Oak Trail 與其說危機，不如說是契機，真的搞出來，我實力會進步得很厲害。

盡信 spec 不如無 spec，但不遵循 spec 做出來的東西就是廢鐵，請密切追蹤本 blog。

別以為你不會碰到 (1)

很多時候，問題都是出在空格上面

result = *x / *y;  //no problem

result = *x/*y;  //compile error

查了好久都不知道為什麼，後來發現… y 被當成多行注解，抹掉了

result = (*x) / (*y); //for your safety

其實有時候不是在寫公司的 code 很懶得去注意 style，上述的方法基本上是沒在用，只能說永遠記得，C 是 maximal munch strategy，你不把運算符切開，它一次就咬住最大口來分析代碼。

經典問題：

a = x+++y;

答案為下列何者？
1.

a = x+       ++y;

2.

a = x++     +y;

思考一下 :)

前進

下單位一個多月了，感覺 leader 和前輩都很好相處，而且大家知識很深，相較之下自己對於相關的東西還嫌太淺，以下簡述。

對硬體的架構和整個 UEFI 的 Bootflow 了解程度仍需加強，一個平台到手上後要先了解全局構造，有什麼部件，基本上就是要把他們推起來，這自然是廢話，要不然焊在板子上做啥？

EFI 的 flow，怎麼走，pei 怎麼去 init，dxemain 怎麼去推 dispatcher，順序、滿足條件，思考了一下，都需要經驗的累積，這部份其實還算好，common knowledge 上網就能查到，畢竟 tiano 在這一塊仍然是公開的。

難是難在不公開的這一段，就需要多問，多學，多筆記。把學習的東西轉成養份，好好去培。

目前 bring up 不是很大的問題，卡是卡在 windows 下要正常 function，這些東西就很機密了，但不違反商機的學習流路未來可以和大家分享一下。

什麼是將才之風？

今天跟朋友聊到 cache as ram 和 ram only 的工程模式，在 google code 上做了一些試驗，發現差異不是一個數量級的。朋友就來了個很妙的問題：大將之風…是什麼？

老實說，我不知道，因為從來沒當過大將。一輩子庸庸碌碌的寫 code，看 code，看算法，寫算法，肚子裡的東西不少，搬得上檯面的不多 (肚子本身除外)。

今天在公司好挫折，一個 20 分鐘就解出來的問題，卻遲遲不敢發，到晚上 8 點才不情願的弄了個 solution。為什麼會這樣，工程思維及經驗的不足導致行動遲滯，這一點再不改進，會是非常恐怖的致命傷。

這輩子錯過不少好機會，這次不會再讓它從指間流走。

關於 cache as ram 的問題可能週末搬過來這邊跟大家討論一下，這期間就做一些 common 的討論，順便寫一些紀錄。

Assembly

下單位之後，整天都在忙 power on，上 feature，自己寫 code 的空間是零。所以最近 leader 放了兩個 assembly 作業，真的超高興，寫得很用心。

組語是本行，寫得真是順手…寫完三個月的 UEFI code，換成組語也是滿恐怖的，沒有語言的保護，直接跟硬體面對面硬幹，有錯誤就毫不留情的噴給你看，這種特性也是蠻值得懷念。

今天又領了經理裝備 (羅西塔小姐的 "來領鋼盔水壺" 的梗不錯笑)，20" 的 LCD，不免俗的普通牌鍵鼠組，8G dongle。螢幕接上去後，coding 果然是爽歪歪，字好大。

這幾天不忙再把 asm code 貼上來分析分享一下。