原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功能太阳春，扩充很麻烦。
但是这其实是二个市场取向不同的东西，不用做太多比较的。