八位微控制器的代碼優(yōu)化技巧

本文將介紹一些優(yōu)化技術(shù)，幫助設(shè)計(jì)人員節(jié)約多達(dá) 10% 的代碼空間，從而讓容量有限的程序存儲(chǔ)器支持更多新特性和補(bǔ)丁。

良好的操作方法

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

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

許多 8 位 CPU 的編譯器包含了很多優(yōu)化程序，不過，這些優(yōu)化程序都有其局限性。如果可以，應(yīng)該盡可能簡(jiǎn)化表達(dá)。例如下面這段代碼：

X = a * CONSTANT1;

X *= CONSTANT2;

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

X = a * CONSTANT1* CONSTANT2;

因?yàn)榫幾g器能將兩個(gè)常量合并為一個(gè)。

優(yōu)化——三思而后行

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

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

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

 

了解支付情況

[!--empirenews.page--]

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

.map 文件的交叉參考表明我們很幸運(yùn)：上述函數(shù)只用于一個(gè)文件中。.lst 文件顯示了長(zhǎng)除法函數(shù)的兩種使用情況以及長(zhǎng)乘法函數(shù)的一種使用情況 

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE * (uint32_t)glNandNumZones;

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

{

char zoneCtr = glNandNumZones;

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE;

while (zoneCtr)

{

glNandDevCapacity <<= 1;

zoneCtr >>= 1;

}

}

盡管這個(gè)例程相當(dāng)大，但它仍能減少庫的使用并減小代碼的整體大小。

掌握比編輯器更多的信息

成熟的 8 位編譯器包括代碼編寫良好、經(jīng)過優(yōu)化的庫函數(shù)。不過，這些函數(shù)須考慮到通過對(duì)數(shù)據(jù)的了解可自行處理的一些不常見情況。映射文件中顯示的最大庫函數(shù)就是這樣一個(gè)很好的例子。調(diào)用兩次 ULDIV 例程，以獲得輸入值除以常量后得到的除數(shù)和余數(shù)： 

zn = (adj_lba / CYAN_NAND_UBLKS_PER_ZONE);

glNandRelativeBlkAddr = (adj_lba % CYAN_NAND_UBLKS_PER_ZONE);

由于我們?cè)陬A(yù)期值方面比編譯器了解的更多，因此我們可以讓編譯器不使用龐大的長(zhǎng)除法函數(shù)，而采用較小的 16 位版本來替代。

{

xdata unsigned char lastNibble = adj_lba & 0xf;

adj_lba >>= 4;

zn = ((uint16_t)adj_lba / (uint8_t)CYAN_NAND_UBLKS_PER_ZONE/16));

glNandRelativeBlkAddr = ((uint16_t)adj_lba % (uint8_t) (CYAN_NAND_UBLKS_PER_ZONE/16));

glNandRelativeBlkAddr = (glNandRelativeBlkAddr << 4) + lastNibble;

}

激進(jìn)的的程序優(yōu)化者甚至可能實(shí)現(xiàn)他們自己的二進(jìn)制長(zhǎng)除法例程。[!--empirenews.page--]

全局變量更好用

將參數(shù)傳遞給函數(shù)是一個(gè)很好的代碼經(jīng)驗(yàn)。在 C 程序中，編譯器可絕對(duì)確保調(diào)用的子程序不會(huì)修改參數(shù)。編譯器可處理存儲(chǔ)器管理的問題。不過，這將占用難以承受的大量時(shí)間和空間。試考慮下面這段代碼：

Main()

{

Int effectiveGlobal;

Foo(effectiveGlobal)

}

由于變量在 main() 中已經(jīng)聲明，因此該變量與真正的全局變量之間的真正差別是命名空間 (namespace)。但是，每次調(diào)用 foo() 時(shí)，編譯器都必須在新的位置存儲(chǔ) effectiveGlobal。聲明真正的全局變量有助于降低因調(diào)用而造成的代碼和數(shù)據(jù)開銷。

向編譯器提供盡可能多的信息

8051 可提供 64K 的地址空間 XDATA、256 字節(jié)的堆棧與間接尋址空間 IDATA 以及 256 字節(jié)的直接尋址空間 DATA 等多個(gè)存儲(chǔ)器空間。在大多數(shù)情況下，代碼編寫人員都知道指針指向了哪個(gè)存儲(chǔ)器空間。如果用戶指定了存儲(chǔ)器空間，編譯器就無需包含對(duì)例程中的所有三類存儲(chǔ)器進(jìn)行尋址的代碼，只需使用一個(gè)即可。由于指針無需包含數(shù)據(jù)空間信息，因此有助于節(jié)約數(shù)據(jù)空間。

在我的 8051 編譯器中，上述變量可通過包含 OPTR 字符串的庫例程進(jìn)行存取。在列表和庫文件中搜索對(duì)OPTR的引用可以發(fā)現(xiàn)長(zhǎng)變量被多次使用，而且由于在代碼中假定了指針的大小，其中某些長(zhǎng)變量還會(huì)導(dǎo)致一些問題。

在變量聲明中使用 const 關(guān)鍵詞可以實(shí)現(xiàn)兩方面的優(yōu)化：第一，編譯器不必再存儲(chǔ)變量的初始值；第二，編譯器能在編譯時(shí)間而非執(zhí)行時(shí)間執(zhí)行一些數(shù) 學(xué) 運(yùn) 算。查看示例程序的編譯輸出，以確定對(duì) const與 #define 的處理是否真的一樣。以下是我對(duì)代碼的測(cè)試：

 

經(jīng)過測(cè)試，得到以下輸出，表明它并不清楚 const 變量的值。

匯編語言

不少嵌入式固件工程師信誓旦旦的表示他們始終能比編譯器做得更好，不僅如此，他們還認(rèn)為應(yīng)該使用匯編語言重新編寫所有代碼。然而事實(shí)上，現(xiàn)代編譯器提供的許多特性已經(jīng)能趕上人腦的水平了。

變量共享：一些 8 位處理器尚無有效的機(jī)制來存取堆棧上的變量。一般的解決方案是創(chuàng)建調(diào)用樹，并在相互不進(jìn)行調(diào)用的函數(shù)間共享變量。在匯編程序中要想保持這種結(jié)構(gòu)相當(dāng)困難，且容易出錯(cuò)。

可靠性：任何從事專業(yè)軟件或固件開發(fā)工作的人員都能讀懂 C 語言程序。如果您需要將代碼交給其它開發(fā)人員處理，他們無需掌握那些為發(fā)揮匯編語言的最大效率而需要的所有技巧便可立即開始修改代碼。

可移植性：C 語言最初的開發(fā)目的之一就是要提供一種非常抽象，以便可以在多種處理器上應(yīng)用的語言。這一目標(biāo)至今仍然非常重要。

代碼共享：許多 8 位編譯器都能在鏈接時(shí)間之后進(jìn)行優(yōu)化，這使得編譯器不僅能執(zhí)行許多人工能完成的優(yōu)化，而且還能完成一些人工所不能完成的優(yōu)化。例如，現(xiàn)在許多編譯器都能搜索不同函數(shù) 中 共 有的代碼字符串，并將其合并為一個(gè)新的函數(shù)。而人類是不可能記住每個(gè)編譯周期中執(zhí)行此函數(shù)所需要的全部細(xì)節(jié)的。

匯編語言現(xiàn)在仍占有一席之地。不過，在使用匯編語言之前應(yīng)首先考慮上述所有因素。

結(jié)論

在撰寫本文的過程中，我將成熟程序的大小從 0x6000 多字節(jié)縮減到了 0x5f2b 字節(jié)，節(jié)約了 200 多字節(jié)。該程序過去曾是多次試圖優(yōu)化程序大小的目標(biāo)。