我之前寫過關于編寫代碼和設計數據結構以優化嵌入式系統中的代碼大小、性能和功率時可以采取的步驟。這種壓縮軟件以適應的需求在早期計算機上很常見，但現在在具有千兆字節內存的普通 64 位系統上幾乎被遺忘了。嵌入式系統將我們帶回到未來，需要恢復這些技能以平衡代碼功能與高度受限的內存容量。

資料來源：CEVA

很多可能的優化將取決于您對代碼的仔細設計和調整。但是構建工具——尤其是編譯器和鏈接器——也可以提供幫助。在本博客中，我將討論可用于 CEVA 工具箱中這些步驟的選項。在所有情況下，我都將專注于優化代碼大小，因為這將是您的主要約束。

編譯器選項

當您設計和調試代碼時，您幾乎肯定會使用-g選項運行，要求生成調試信息。使用此選項運行可防止編譯器執行任何可能以使調試復雜化的方式扭曲代碼的優化。當您認真考慮優化代碼大小時，您將不得不刪除該選項。

下一個考慮因素是編譯器如何選擇優化。默認情況下，它將通過多種方法優化性能。一種方法將通過為循環的每次迭代復制代碼來展開（有限大小）for循環。這避免了在每次迭代時設置和測試循環索引的開銷，但顯然會消耗更多內存。使用-Oz選項將阻止展開，更喜歡較小且稍慢的實現。

編譯器可以用來優化性能的另一個選項是內聯某些函數（特別是小函數）。這可以消除將參數推入和彈出堆棧以及跳入和跳出被調用函數的開銷。但是，如果多次調用該函數，它將再次增加代碼大小。使用-INLINE=no選項來禁止這種自動內聯。

另一種優化在傳統平臺上似乎不值得付出努力，但可以對 DSP 上的代碼大小產生重要影響。這是為了禁用（視情況而定）編譯器對指針別名的保護。這種保護的目的是確保在選擇在VLIW機器上并平行一組指令（例如DSP）時，編譯器將確保這些說明中的任何指針參考在兩個或更多的情況下都無法進入比賽條件其中指向同一位數據。這會限制某些指令可以并行運行的程度。您可以使用選項-alias=restrict強制解釋不會發生此類情況，這應該允許推斷出更多的并行性。當然，您應該仔細檢查并完全回歸，以確保這種解釋是安全的。

鏈接器

鏈接器還可以執行與大小相關的優化。其中之一是刪除未引用的函數。這需要一些小心。一些函數可以通過數據指針甚至直接跳轉到硬編碼地址來調用。而中斷服務函數通常通過傳統的調用協議來訪問。因此這個選項必須考慮多種可能性。它將被自動調用，并且可以使用-keepUnrefFuncs選項禁用。

另一個鏈接器優化可以進一步減小代碼的大小，其中某些符號未被匯編器解析，以便在鏈接時進行尋址。由于它們開始未解析，因此匯編器必須假定最大可能的大小來尋址目標處理器，當最終在鏈接器中解析時，這實際上可能是浪費的。如果不采取特殊措施，許多此類符號可能會解析為非常小的地址，但仍會占用最大可能的地址字長。縮小這些位置可以顯著縮小總代碼大小。這是另一個微妙的任務。在縮小任何給定地址時，必須調整代碼中任何位置對該符號后面位置的直接引用。還必須考慮數據對齊要求（有時是特定于處理器的）。每次減少都必須考慮最佳最小編碼，不僅對節省空間的影響，而且對其余代碼的影響。幸運的是，這些優化是默認執行的。

結合最佳編碼實踐，謹慎使用這些編譯器和鏈接器選項可以幫助進一步縮小代碼和數據大小，以最具成本效益的方式適應您的嵌入式系統。這反過來又增加了您作為經驗豐富的嵌入式系統程序員的價值，這始終是一個理想的目標！

審核編輯 黃昊宇