原PO有二個問題需要思考:
1.程式的可讀性，就你寫的語法在BIOS裡面是非常少見的，
你該思考的是如果有人看不懂你寫的東西，你要跟多少人解釋？
如果你的工作是OEM端，那你可能頂多跟客戶解釋就好了，
可是如果你做的是kernel或者是module owner，你要解釋的人就非常多了。
2.AMI BIOS並不是用keil來compiler BIOS。
你確定你寫的東西AMI compiler tools看得懂嗎？
如果你真的進了AMI，但是你寫的東西AMI compiler tools看不懂，
請問你要改寫法嗎？
你寫的東西雖然沒有問題，組譯出來也是最佳化，
但是BIOS的環境不適合，你的想法就該有所改變。
如果你想拿著這行程式去問每個面試的老闆，
抱著非看得懂這行程式的老闆不要的心態，那我會替你加油的。
轉換個心態，其實程式都是一樣的，
一個hollo world有幾萬種寫法，
這寫法人家看不懂，換個寫法寫也不會花太多時間對吧？
另外討論Wolfload大大的想法，
事實上W大有些想法是對的，也讓我想到前段時間intel推出的BLDK架構。
BLDK架構簡單來說就是給你一包包括kernel，NB，SB，CPU等幾個module，
就能compiler出一個BIOS。
這樣的BIOS執行速度相當快，3-5秒就能進OS，消耗資源相當少，
可是功能相當陽春。
反觀AMI BIOS，一整包code 100多MB，compiler要快十分鐘，重複且沒必要的定義不少，
開機要不少時間，但是功能相當的完整，
基本上可以support各家晶片組的各種特殊功能。
看得出差別嗎？ 市場取向不同。
BLDK針對的是簡單且特定功能的機器，例如醫療設備，
像醫療設備的話，我可能只需要kernel，NB，SB以及CPU這四個module，
我不需要ACPI，不需要SMBIOS，SMI，所以我就都不加避免資源浪費。
但是AMI BIOS光要disable這四個module，compiler部分就會瘋掉了。
所以AMI針對的是比較大型的機器，例如筆電，桌機，以及server等等的。
像做BLDK的人可能就會認為AMI BIOS在幹嘛？沒必要的東西包一堆。
AMI BIOS就會覺得BLDK功能太陽春，擴充很麻煩。
但是這其實是二個市場取向不同的東西，不用做太多比較的。