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

嵌入式大雜燴

▲ 點(diǎn)擊上方藍(lán)字關(guān)注我們，不錯(cuò)過任何一篇干貨文章！工欲善其事，必先利其器，對(duì)嵌入式工程師來說，嵌入式編譯器是不可或缺的神兵利器，它被人冠以“C語(yǔ)言翻譯官”的名號(hào)。 由于C語(yǔ)言歷史悠久，早期沒有規(guī)范，整個(gè)計(jì)算機(jī)產(chǎn)業(yè)也都處于拓荒的年代，所以就涌現(xiàn)了很多款C語(yǔ)言編譯器。
根據(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，作為一個(gè)完全開源的編譯器，很多MCU廠商的IDE都由它改寫而來。但最近一段時(shí)間，業(yè)界出現(xiàn)不同的聲音，表示“開源才是最貴的”，這些編譯器在開源背后潛藏許多隱形成本。付斌｜作者
電子工程世界（ID：EEWorldbbs）｜出品

RTOS中，GCC沒打過IAR


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

RTOS測(cè)試     ThreadX

基準(zhǔn)測(cè)試     74%

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

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

消息處理     41%

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

同步處理     32%
也許會(huì)有人說，編寫代碼的質(zhì)量決定了性能好壞。這句話確實(shí)沒錯(cuò)，人們可以花費(fèi)大把時(shí)間，細(xì)致地優(yōu)化代碼，但這不意味著開發(fā)時(shí)間更長(zhǎng)，開發(fā)成本更高？比如說，一些IoT項(xiàng)目工期比較短，有時(shí)候如果沒有來得及去優(yōu)化，那可能GCC處理時(shí)間會(huì)增加20%，并且讓電池更費(fèi)電。又或者，GCC編譯的代碼可能體積也會(huì)更大，這時(shí)候，內(nèi)存從120MHz就需要變相升級(jí)到200MHz，這幾塊錢的差距，就會(huì)讓產(chǎn)品成本大幅度增加。GCC的確是行業(yè)一個(gè)福音，但相比商業(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)。在工程師群里，很多人都提到一個(gè)話題，就是Keil的ArmCC編譯器很神。那么實(shí)際情況如何呢？根據(jù)工程師的測(cè)試，可以得知，GCC的編譯速度最快（Keil和VisualGDB都開啟多線程編譯的）。而bin體積最小的是ArmCC V5。代碼的執(zhí)行效率沒有測(cè)。而ArmCC V5和V6對(duì)比，編譯用時(shí)差異不大，手動(dòng)掐表可以認(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
編譯用時(shí)(秒)	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	- -	- -	- -
編譯用時(shí)(秒)	7.93	8.25	8.15	9.68	- -	- -	- -
GCC  7.2	bin大小(KB)	176	135	136	144	- -	129	- -
編譯用時(shí)(秒)	3.49	3.63	3.68	4.12	- -	3.96	- -

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

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

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

用誰，工程師各持己見


蘿卜青菜各有所愛，不論如何測(cè)試，工程師總是有自己的偏好。因?yàn)楣�司需求不同，�?duì)于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í)際確不會(huì)執(zhí)行。很多人表示，習(xí)慣了。有人更喜歡用IAR，IAR不僅比Keil便宜很多，而且還內(nèi)置了misra靜態(tài)檢查工具，很方便。有傳統(tǒng)GCC派，gdb調(diào)試Vscode編輯，在Linux系統(tǒng)下編譯很香，有些老板不在意Flash的情況下，可以有最快的交付速度。也有Clion、Clang之類的新派。那么，你怎么看待不同編譯器之間的差異問題，你又會(huì)選用什么編譯器？
參考文獻(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 語(yǔ)言項(xiàng)目匯總！
嵌入式，可測(cè)試性軟件設(shè)計(jì)！
一些低功耗軟件設(shè)計(jì)的要點(diǎn)！
嵌入式 C 保護(hù)結(jié)構(gòu)體的方式
實(shí)用 | 10分鐘教你通過網(wǎng)頁(yè)點(diǎn)燈
談?wù)勄度胧杰浖�的兼容性�?/strong>