開源嵌入式編譯器，沒想象中那么好？

嵌入式大雜燴

▲ 點(diǎn)擊上方藍(lán)字關(guān)注我們，不錯過任何一篇干貨文章！工欲善其事，必先利其器，對嵌入式工程師來說，嵌入式編譯器是不可或缺的神兵利器，它被人冠以“C語言翻譯官”的名號。 由于C語言歷史悠久，早期沒有規(guī)范，整個計算機(jī)產(chǎn)業(yè)也都處于拓荒的年代，所以就涌現(xiàn)了很多款C語言編譯器。
根據(jù)EEWorld的調(diào)研，嵌入式工程師比較青睞的嵌入式編譯器主要包括Keil（ArmCC）、IAR、GCC、AVR GCC、CLion、Clang、green hills、TI的CSS、ADI的Visual DSP++。不過，隨著嵌入式開發(fā)格局逐漸穩(wěn)固，Keil、IAR、GCC成為嵌入式編譯器三巨頭，基本大部分嵌入式產(chǎn)品都有其身影。尤其是GCC，作為一個完全開源的編譯器，很多MCU廠商的IDE都由它改寫而來。但最近一段時間，業(yè)界出現(xiàn)不同的聲音，表示“開源才是最貴的”，這些編譯器在開源背后潛藏許多隱形成本。付斌｜作者
電子工程世界（ID：EEWorldbbs）｜出品

RTOS中，GCC沒打過IAR


現(xiàn)如今，“C/C++與RTOS結(jié)合使用”是嵌入式軟件開發(fā)的黃金范式，所以在嵌入式領(lǐng)域，判別編譯器好不好用，那一定是在RTOS上好用。根據(jù)著名嵌入式Jacob Beningo的測試，使用IAR編譯時，RTOS指標(biāo)性能比使用GCC編譯時要好得多。根據(jù)公制測試，結(jié)果略有不同，但通常要好20～40%。以其中一個示例結(jié)果為例，該示例將IAR指標(biāo)結(jié)果除以 ThreadX（Eclipse ThreadX）的GCC指標(biāo)結(jié)果。

RTOS測試     ThreadX

基準(zhǔn)測試     74%

系統(tǒng)調(diào)度     3%

內(nèi)存分配測試 28%

消息處理     41%

搶占式調(diào)度     19%

同步處理     32%
也許會有人說，編寫代碼的質(zhì)量決定了性能好壞。這句話確實(shí)沒錯，人們可以花費(fèi)大把時間，細(xì)致地優(yōu)化代碼，但這不意味著開發(fā)時間更長，開發(fā)成本更高？比如說，一些IoT項(xiàng)目工期比較短，有時候如果沒有來得及去優(yōu)化，那可能GCC處理時間會增加20%，并且讓電池更費(fèi)電。又或者，GCC編譯的代碼可能體積也會更大，這時候，內(nèi)存從120MHz就需要變相升級到200MHz，這幾塊錢的差距，就會讓產(chǎn)品成本大幅度增加。GCC的確是行業(yè)一個福音，但相比商業(yè)編譯器，也許它本身也存在一定額外的隱形開銷�？茨壳癛TOS抑或是開源RTOS本身也是附帶工具鏈的，大部分則只支持GCC，卻不支持商業(yè)編譯器IAR，這種情況導(dǎo)致客戶選擇面變窄。

Keil比GCC編譯文件，更小


雖然Keil目前已經(jīng)包括五種版本，其中不乏全免費(fèi)的教育版，而且STM32之類的MCU使用Keil也是免費(fèi)的，但如果做一些很深入的開發(fā)工作，Keil本身還是需要付費(fèi)的。所以它實(shí)質(zhì)上還是算在商業(yè)編譯器范疇內(nèi)。在工程師群里，很多人都提到一個話題，就是Keil的ArmCC編譯器很神。那么實(shí)際情況如何呢？根據(jù)工程師的測試，可以得知，GCC的編譯速度最快（Keil和VisualGDB都開啟多線程編譯的）。而bin體積最小的是ArmCC V5。代碼的執(zhí)行效率沒有測。而ArmCC V5和V6對比，編譯用時差異不大，手動掐表可以認(rèn)為是誤差范圍內(nèi)。但是bin體積V5比V6小很多。

	優(yōu)化選項(xiàng)	O0	O1	O2	O3	Ofast	Os	Oz
ARMCC  V6.9	bin大小(KB)	131.13	90.03	95.54	98.54	97.45	87.84kB	85.47
編譯用時(秒)	7.23	7.52	7.99	8.3	8.4	8.17	7.64
ARMCC  V5.06	bin大小(KB)	77.18	64.49	61.19	61.44	- -	- -	- -
編譯用時(秒)	7.93	8.25	8.15	9.68	- -	- -	- -
GCC  7.2	bin大小(KB)	176	135	136	144	- -	129	- -
編譯用時(秒)	3.49	3.63	3.68	4.12	- -	3.96	- -

為什么有時候會出現(xiàn)文件大小區(qū)別的情況？有工程師也曾經(jīng)遇到過GCC編譯bin文件比ArmCC大的情況，通過捋順代碼，發(fā)現(xiàn)有些原廠本身做了一些優(yōu)化工作，所以實(shí)際上這本身也就節(jié)省了工程師優(yōu)化的時間。也有工程師表示，Keil有Keil的優(yōu)勢，GCC有GCC的優(yōu)勢，二者大多數(shù)情況下不可兼得；Keil（ArmCC）編譯對Arm芯片有天然的優(yōu)勢，無論從代碼性能和代碼尺寸都有更佳的表現(xiàn)；GCC優(yōu)勢在于開源，利于折騰。也有工程師在m0上做了實(shí)驗(yàn)，使用同樣的代碼觸發(fā)pendsv中斷，ArmCC響應(yīng)時間為68clocks，gcc響應(yīng)時間為78clocks。他表示，雖然ArmCC不開源、不免費(fèi)、不可控，但是它會更代碼執(zhí)行效率更高。

ArmCC中斷響應(yīng)匯編

GCC中斷響應(yīng)匯編

用誰，工程師各持己見


蘿卜青菜各有所愛，不論如何測試，工程師總是有自己的偏好。因?yàn)楣�司需求不同，對于Flash、執(zhí)行速度、交付等要求不同，使用不同編譯器都有不同的結(jié)果。喜歡Keil的，在實(shí)際體驗(yàn)中，ac6的Osize優(yōu)化特別猛，性能稍微弱一丟丟，但是體積特別小，其它編譯器都比不過，同樣的程序比gcc能小四分之一。但它讓人又愛又恨，就比如MDK AC6曾經(jīng)出現(xiàn)過調(diào)試到處亂跳的問題，不過商業(yè)版本有所改善，或者說MDK經(jīng)常把if-else結(jié)構(gòu)優(yōu)化成IT匯編指令，在反匯編窗口中打的斷點(diǎn)都命中了實(shí)際確不會執(zhí)行。很多人表示，習(xí)慣了。有人更喜歡用IAR，IAR不僅比Keil便宜很多，而且還內(nèi)置了misra靜態(tài)檢查工具，很方便。有傳統(tǒng)GCC派，gdb調(diào)試Vscode編輯，在Linux系統(tǒng)下編譯很香，有些老板不在意Flash的情況下，可以有最快的交付速度。也有Clion、Clang之類的新派。那么，你怎么看待不同編譯器之間的差異問題，你又會選用什么編譯器？
參考文獻(xiàn)
[1]https://www.embedded.com/the-hidden-costs-of-open-source-compilers[2]https://www.zhihu.com/question/26864086/answer/280900095[3]https://club.rt-thread.org/ask/article/866813c0a2efd608.html[4]https://www.bilibili.com/video/BV18h4y1v7yR

猜你喜歡：
WiFi6+藍(lán)牙+星閃，三合一開發(fā)板，真香！
Github上熱門 C 語言項(xiàng)目匯總！
嵌入式，可測試性軟件設(shè)計！
一些低功耗軟件設(shè)計的要點(diǎn)！
嵌入式 C 保護(hù)結(jié)構(gòu)體的方式
實(shí)用 | 10分鐘教你通過網(wǎng)頁點(diǎn)燈
談?wù)勄度胧杰浖�的兼容性�?/strong>