arm設計進階(編輯修改稿)
2025-03-27 12:38 本頁面
【文章內容簡介】 ? RVDS對代碼密度的提升、代碼執(zhí)行速度的提高，都可以由 ARM開發(fā)工具自動實現，而不需要軟件開發(fā)人員花費過多的時間手動優(yōu)化高級語言代碼。這是 RVDS的優(yōu)勢所在。 ? 先前版本中的編譯器 armcc， tcc，armcpp， tcpp 已經整合成一個編譯器armcc，可以將標準的 C或 C++語言源程序編譯成 32位 ARM指令代碼或者 16位 Thumb指令代碼或者 Thumb2指令代碼。編譯器輸出的 ELF格式的目標文件，包含調試信息。除此之外，編譯器可以輸出所生成的匯編語言列表文件。 ? RVDS的編譯器根據最新的 ARM架構進行特別的優(yōu)化，針對每個 ARM架構都提供最好的代碼執(zhí)行性能，最優(yōu)的代碼密度?？梢愿鶕枰x擇調試信息級別，以及不同的代碼優(yōu)化方向和優(yōu)化級別。 RVCT中 C 和 RogueWaveC++庫包括 ? 完整 ISO標準 C語言庫 標準 C語言函數集， C語言庫需要的支持函數以及在 Semihosted執(zhí)行環(huán)境中需要的目標相關的函數。 ARM C語言庫結構使用戶很容易定義目標相關函數，以適應特定的目標環(huán)境。 ? 浮點函數庫使用 ARM 在 IEEE754標準（二進制浮點算法）上實現的浮點環(huán)境。 RogueWaveC++庫 RogueWaveC++庫包含標準 C++函數，編譯器需要的支持函數。 各種源文件經過 ARM編譯器編譯后生成 ELF 格式的目標文件。這些目標文件和相應的 C/C++運行時庫經過 ARM連接器處理后，生成 ELF格式映像文件。 ? 通常在 嵌入式 系統中，指令和數據代碼會固化在非易失性存儲器中（ ROM或 Flash），可以從這些地方上電啟動。從運行速度方面考慮，部分指令和數據代碼會在啟動后搬運到易失性存儲器 (RAM)中，因此連接器可以使用一些方法機制來配置調度。 ? 這種分散裝載（ scatterloading）的機制可以讓把不同的指令和數據分散的放到不同的地址，而且這些地址在系統啟動和系統運行可以是不同的映射。 詳細的地址分配可以是用參數來指定，或者用一個描述文件來作為連接器的參數。使用描述文件會使維護起來非常簡單，而且如果要改變地址分配，不需要把整個項目完全重新來做，只要把項目中需要的目標重新連接即可。 一個 scatterloading文件的示例： ? LOAD_FLASH 0x04000000 0x80000 。 啟動地址和長度 { EXE_FLASH 0x04000000 0x80000 { (Init, +First) 。 * (+RO) 。 } 32bitRAM 0x0000 0x2023 { (Vect, +First) 。 (+RO) } 16bitRAM 0x2023 0x80000 { * (+RW,+ZI) ? 。 } } ? 本文件定義了啟動區(qū)域和三個執(zhí)行區(qū)域。在大括號外面定義了啟動區(qū)域（ LOAD_FLASH），里面三個定義了執(zhí)行區(qū)域 (EXEC_FLASH,32bitRAM,16bitRAM)。 為了提高運行速度，異常向量（在 ）和異常句柄（在 ）被重新放置到 32bitRAM的零地址開始的地方。 可以讀寫的變量被復制到 16bitRAM的 0x2023地址開始的地方。 零初始化的數據和可讀寫數據放在 16bitRAM內。 其他不需要搬運的代碼只需要還放在 Flash里就好。 RVCT 的優(yōu)化級別與優(yōu)化方向 ? 提到 RVCT就不能不提 ARMcc的四個優(yōu)化級別和兩個編譯選項， O O O O4，以及 Otime、 Ospace。 Ospace與 Otime負責給編譯器提供代碼優(yōu)化的大方向，告知編譯器編譯任務的主要目標是代碼密度（ Ospace）還是代碼性能（ Oti ? me）。而 O O O O4則分別代表 4種逐次遞進的不同優(yōu)化級別。 OSpace 還是 OTime？ ? 顯然代碼密度與代碼執(zhí)行速度在很多情況下是一對矛盾。以下面的代碼為例。例 1中左右兩段代碼可以完成相同的任務，但是左邊的有較高的代碼密度，右邊的則有較高的執(zhí)行速度。因為當expr = 0時，標志循環(huán)結束時，右邊的代碼可以順序執(zhí)行下去；而左邊代碼必須先跳轉至循環(huán)體首部判斷 expr的值，隨后再跳轉道循環(huán)體尾，繼續(xù)執(zhí)行下一條指令。 ? 例 1 代碼速度與尺寸的對比 while (expr) if (expr) do { { do body。 { body。 } while (expr)。 } } ? 那么我們什么時候使用 Otime 什么時候使用Ospace呢？ Otime與 Ospace需要 開發(fā) 人員根據系統實際需求來決定，最好的情況是在兩者之間找到一個合適的平衡點，而不是單純的追求速度或者代碼尺寸的縮小。即，將不同的代碼模塊根據其特性分別使用不同的編譯選項。
環(huán)評公示相關推薦
鄂ICP備17016276號-1