本文將介紹一些優化技術，幫助設計人員節約多達 10% 的代碼空間，從而讓容量有限的程序存儲器支持更多新特性和補丁。

良好的操作方法

許多程序員在 32 位處理器上學習編寫軟件，如 Intel 的 Pentium 處理器或某種 ARM 平臺。不過，嵌入式領域的軟件編寫需要不同的思路。在 32 位 CPU 上，存儲比特位的最佳方法通常是使用 32 位變量。對 8 位處理器而言，最好的辦法就是采用單字節。像增強型 8051s 等某些處理器可能提供特殊的 1 位變量。

嵌入式處理器通常會超出標準的哈佛架構將存儲器分散到不同的存儲器空間中，有的相互重疊，有的又是相互分離。例如，8051 中常見的存儲器空間包括 CODE、XDATA、DATA、IDATA、BIT 以及寄存器等。當要決定在何處存放變量時，了解每個存儲器空間的優缺點顯得非常重要，特別是在各個存儲空間的容量都有限時更是如此。例如，IDATA 空間可能只能運行 256 個字節，不過它為間接存取進行了優化。雖然 DATA 空間也只能運行 256 個字節，但它包括了 位可尋址空間和寄存器。盡管 CODE 和 XDATA 只能通過慢速間接存取機制進行訪問，但它們的尋址空間卻高達 64K。

許多 8 位 CPU 的編譯器包含了很多優化程序，不過，這些優化程序都有其局限性。如果可以，應該盡可能簡化表達。例如下面這段代碼：

X = a * CONSTANT1;

X *= CONSTANT2;

通常要比下述代碼多占空間:

X = a * CONSTANT1* CONSTANT2;

因為編譯器能將兩個常量合并為一個。

優化——三思而后行

經驗豐富的木匠都知道做事應該事先作好計劃，三思而后行。嵌入式固件工程師也應該遵循這一原則。所有嵌入式編譯器都提供了一個可給出有用信息映射文件。如圖 1 所示，該映射文件提供了本文所用代碼示例的有用信息。圖中所示的庫 (LIB_CODE) 使用的空間超過了 1K，而且啟動代碼 (c51startup) 使用的代碼超過了 140 字節。

進行優化的另一原因是可以節約時間。在優化之前，衡量程序的性能尤為重要。顯而易見，如果源文件過大，肯定會占用大量的存儲器空間，但我們很難測定代碼的哪些關鍵部分在消耗寶貴的 MIPS。在此過程中，我們可將程序概要分析 (Profiling) 作為一個重要的工具來加以利用。

我們可利用未使用的單一輸出引腳來進行程序概要分析，不過輸出引腳越多，分析也就越容易。我們可創建一個宏來設置程序概要分析輸出，如下所示，再將宏放在每個例程的起點和終點處。

?

了解支付情況

在上述的映射文件中，我們了解到庫占用了 1K 的寶貴存儲器空間。深入查看映射文件，通過 Excel 進行分析后得到了如圖 2 所示的結果。我們從圖中移出較小的庫函數部分。盡管這些函數名稱比較晦澀，不過我們可以對照庫參考資料逐一了解其含義。首先，ULDIV 是指無符號數的長除法 (long division)，而圖中第二個則是指長乘法 (long multiplication)。

.map 文件的交叉參考表明我們很幸運：上述函數只用于一個文件中。.lst 文件顯示了長除法函數的兩種使用情況以及長乘法函數的一種使用情況?

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE * (uint32_t)glNandNumZones;

在該特定案例中，我們知道 zone 的數量是一個二進制數，而另兩個值為常量。因此，我們可用重復 8 次的左移位 (left shift) 操作替代長乘法：

{

char zoneCtr = glNandNumZones;

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE;

while (zoneCtr)

{

glNandDevCapacity <<= 1;

zoneCtr >>= 1;

}

}

盡管這個例程相當大，但它仍能減少庫的使用并減小代碼的整體大小。