※ 引述《kikiqqp (喵食罐頭)》之銘言：
: 這裡是 asm版，先用 asm的方式說明
: 一般來說在組語 快的程式通常大而且直觀，相反的慢的程式通常小
這不一定
: 這是單純的拿程式空間來換取速度，當你只有 1K時，別說用 JMP了
: 直接 PC跳躍都會拿來用。
1K到底大不大還是要看要塞多少功能才知道.
真的碰到code size那麼吃緊的狀況,
一開始可能就要好好評估是不是用asm寫; 或是換容量更大的mcu.
rom size現在不那麼值錢了, 我之前做小東西用C寫完才2K左右,
選用的mcu系列容量最小的是4K, 但代理商報價最便宜的是8K那顆,
因為用量最大.
: 但在 C語言就不同了，編譯器會編出什麼鬼玩意很少人會去探討
至少在mcu這塊, 我認識的有相當經驗與程度的programmer對C code會編
出怎樣的asm都還算瞭解.
事實上不管在什麼環境寫程式效能都是追求的目標.
例如在PC寫影像處理程式可能就要meet 30fps的要求,
web service在request很多時也要確保速度夠快以免lag.
追求效能當然會改寫程式, 但並不構成讓程式'醜'的充份理由.
: 傳統上會希望寫程式的人能夠模組化結構化，都用function的寫法
那些部份要切成function是應該在程式規劃時要考慮清楚,
不管PC或mcu都一樣.
: 不用去管Stack炸掉的問題
除非程式有bug不然stack炸掉很少見吧.
像51這樣的mcu的compiler基本上不太支援recursion,
把stack寫到炸掉也蠻厲害的.
: 但是
: 進入 function(CALL)和返回 return(RETFIE)實際上是很慢的，還不如用goto(JMP)
假如連 function call, return的 overhead都要計較,
那這個project可能不適合用C實作.
C的overhead可不只call/return而已,
光改進call/return部份效果可能也有限.
一般程式1000行, 真正跟效能有關的可能只有100行.
mcu程式可能就isr部份跟少數幾個loop(的一部份),
在這些部份採用高效能的程式寫法才比較有意義,
但是高效能的寫法不見得必然產生'醜'程式.
: 很多人很痛恨goto，說會破壞結構，但在單晶片下這被編譯後玩意跑的很快
大部份人都認為在特定的狀況下用goto是適當且有好處的, 只是要小心且不建議
新手濫用. 在C_and_CPP板有一些goto的討論, 沒人說goto不能用吧. Knuth還寫
過文章說明在某些狀況下用goto可得到最佳結構.
參見wiki: http://zh.wikipedia.org/wiki/Goto
: 在需要快的情況且必要可讀性下，只能狂用 macro或善用前處理器來處理
: 麻煩的事情，如位元讀取或變換: macro就是浪費空間且好讀，但就是快，畢竟不是所有編譯器都支援 inline的寫法
PC 的 C 也很常用很多 macro, 用macro不代表程式會變'醜'吧?
其實我們應該先釐清對程式'醜'的認知到底有那些異同,
不然說那麼多可能都是雞同鴨講. 方便的話請你舉個明確的例子說明
怎樣的程式叫'醜', 然後我們再來討論'醜'是否是必要且不可避免的.