|
▲ 點擊上方藍字關(guān)注我們,不錯過任何一篇干貨文章!工欲善其事,必先利其器,對嵌入式工程師來說,嵌入式編譯器是不可或缺的神兵利器,它被人冠以“C語言翻譯官”的名號。 由于C語言歷史悠久,早期沒有規(guī)范,整個計算機產(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)|出品
kt4aqd2k1ep64026634917.png (236 Bytes, 下載次數(shù): 3)
下載附件
保存到相冊
kt4aqd2k1ep64026634917.png
2024-9-12 11:48 上傳
RTOS中,GCC沒打過IAR
ynm5wfmph1g64026635017.png (237 Bytes, 下載次數(shù): 2)
下載附件
保存到相冊
ynm5wfmph1g64026635017.png
2024-9-12 11:48 上傳
現(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ì)量決定了性能好壞。這句話確實沒錯,人們可以花費大把時間,細致地優(yōu)化代碼,但這不意味著開發(fā)時間更長,開發(fā)成本更高?比如說,一些IoT項目工期比較短,有時候如果沒有來得及去優(yōu)化,那可能GCC處理時間會增加20%,并且讓電池更費電。又或者,GCC編譯的代碼可能體積也會更大,這時候,內(nèi)存從120MHz就需要變相升級到200MHz,這幾塊錢的差距,就會讓產(chǎn)品成本大幅度增加。GCC的確是行業(yè)一個福音,但相比商業(yè)編譯器,也許它本身也存在一定額外的隱形開銷。看目前RTOS抑或是開源RTOS本身也是附帶工具鏈的,大部分則只支持GCC,卻不支持商業(yè)編譯器IAR,這種情況導(dǎo)致客戶選擇面變窄。
Keil比GCC編譯文件,更小
雖然Keil目前已經(jīng)包括五種版本,其中不乏全免費的教育版,而且STM32之類的MCU使用Keil也是免費的,但如果做一些很深入的開發(fā)工作,Keil本身還是需要付費的。所以它實質(zhì)上還是算在商業(yè)編譯器范疇內(nèi)。在工程師群里,很多人都提到一個話題,就是Keil的ArmCC編譯器很神。那么實際情況如何呢?根據(jù)工程師的測試,可以得知,GCC的編譯速度最快(Keil和VisualGDB都開啟多線程編譯的)。而bin體積最小的是ArmCC V5。代碼的執(zhí)行效率沒有測。而ArmCC V5和V6對比,編譯用時差異不大,手動掐表可以認為是誤差范圍內(nèi)。但是bin體積V5比V6小很多。
| 優(yōu)化選項 | 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)化工作,所以實際上這本身也就節(jié)省了工程師優(yōu)化的時間。也有工程師表示,Keil有Keil的優(yōu)勢,GCC有GCC的優(yōu)勢,二者大多數(shù)情況下不可兼得;Keil(ArmCC)編譯對Arm芯片有天然的優(yōu)勢,無論從代碼性能和代碼尺寸都有更佳的表現(xiàn);GCC優(yōu)勢在于開源,利于折騰。也有工程師在m0上做了實驗,使用同樣的代碼觸發(fā)pendsv中斷,ArmCC響應(yīng)時間為68clocks,gcc響應(yīng)時間為78clocks。他表示,雖然ArmCC不開源、不免費、不可控,但是它會更代碼執(zhí)行效率更高。
grknm1m3eru64026635118.png (1.42 MB, 下載次數(shù): 2)
下載附件
保存到相冊
grknm1m3eru64026635118.png
2024-9-12 11:48 上傳
ArmCC中斷響應(yīng)匯編
1pyo4bdougs64026635218.png (1.34 MB, 下載次數(shù): 3)
下載附件
保存到相冊
1pyo4bdougs64026635218.png
2024-9-12 11:48 上傳
GCC中斷響應(yīng)匯編
用誰,工程師各持己見
蘿卜青菜各有所愛,不論如何測試,工程師總是有自己的偏好。因為公司需求不同,對于Flash、執(zhí)行速度、交付等要求不同,使用不同編譯器都有不同的結(jié)果。喜歡Keil的,在實際體驗中,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匯編指令,在反匯編窗口中打的斷點都命中了實際確不會執(zhí)行。很多人表示,習(xí)慣了。有人更喜歡用IAR,IAR不僅比Keil便宜很多,而且還內(nèi)置了misra靜態(tài)檢查工具,很方便。有傳統(tǒng)GCC派,gdb調(diào)試Vscode編輯,在Linux系統(tǒng)下編譯很香,有些老板不在意Flash的情況下,可以有最快的交付速度。也有Clion、Clang之類的新派。那么,你怎么看待不同編譯器之間的差異問題,你又會選用什么編譯器?
參考文獻
[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+藍牙+星閃,三合一開發(fā)板,真香!
Github上熱門 C 語言項目匯總!
嵌入式,可測試性軟件設(shè)計!
一些低功耗軟件設(shè)計的要點!
嵌入式 C 保護結(jié)構(gòu)體的方式
實用 | 10分鐘教你通過網(wǎng)頁點燈
談?wù)勄度胧杰浖募嫒菪裕?/strong> |
|