※ 引述《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不代表程式会变'丑'吧?
其实我们应该先厘清对程式'丑'的认知到底有那些异同,
不然说那么多可能都是鸡同鸭讲. 方便的话请你举个明确的例子说明
怎样的程式叫'丑', 然后我们再来讨论'丑'是否是必要且不可避免的.