上面的代碼中，循環(huán)是臃腫的，變量 j 完全不必要，那么將代碼改成

UCHAR i;

UCHAR j;

for(i = 0; i LEN; ++i )

{

tt1[i] = 0x55;

}

再編譯看看，出錯(cuò)了吧!

因?yàn)?a class="contentlabel" href="http://cafeforensic.com/news/listbylabel/label/編譯器">編譯器不知道該如何使用 j，所以沒(méi)能優(yōu)化，j 須占 RAM 空間，RAM 就溢出了。

(智能一點(diǎn)的編譯器會(huì)自動(dòng)將這個(gè)無(wú)用的變量去掉，但這個(gè)不在討論之列了)

另外，對(duì) idata 的定義的變量最好放在 data 變量之后

對(duì)于這一種定義

uchar c1;

idata uchar c2;

uchar c3;

變量 c2 肯定會(huì)以間接尋址，但它有可能落在 data 區(qū)域，就浪費(fèi)了一個(gè)可直接尋址的空間

變量?jī)?yōu)化一般要注意幾點(diǎn):

①讓盡可能多的變量使用直接尋址，提高速度

假如有兩個(gè)單字節(jié)的變量，一個(gè)長(zhǎng)119的字符型數(shù)組

因?yàn)榭傞L(zhǎng)超過(guò) 120 字節(jié)，不可能都定義在 data 區(qū)

按這條原則，定義的方式如下:

data UCHAR tab[119];

data UCAHR c1;

idata UCHaR c2;

但也不是絕的，如果 c1, c2 需要以極高的頻率訪問(wèn)，而 tab 訪問(wèn)不那么頻繁

則應(yīng)該讓訪問(wèn)量大的變量使用直接尋址：

data UCAHR c1;

data UCHaR c2;

idata UCHAR tab[119];

這個(gè)是要根據(jù)具體項(xiàng)目需求來(lái)確定的

②提高內(nèi)存的重復(fù)利用率

就是盡可能的利用局部變量，局部變量還有個(gè)好處是訪問(wèn)速度比較快

由前面的例子可以看出，局部變量 i, j 是沒(méi)有單獨(dú)占用內(nèi)存的

子程序中使用內(nèi)存數(shù)目不大的變量盡量定義為局部變量

③對(duì)于指針數(shù)組的定義，盡可能指明存儲(chǔ)類(lèi)型

盡量使用無(wú)符號(hào)類(lèi)型變量

一般指針需要一個(gè)字節(jié)額外的字節(jié)指明存儲(chǔ)類(lèi)型

8051 系列本身不支持符號(hào)數(shù)，需要外加庫(kù)來(lái)處理符號(hào)數(shù)，一是大大降低程序運(yùn)行效率，二是需要額外的內(nèi)存

④避免出現(xiàn)內(nèi)存空洞

可以通過(guò)查看編譯器輸出符號(hào)表文件(.M51)查看

對(duì)前面的代碼，M51文件中關(guān)于內(nèi)存一節(jié)如下：

* * * * * * * D A T A M E M O R Y * * * * * * *

REG 0000H 0008H ABSOLUTE "REG BANK 0"

DATA 0008H 0078H UNIT ?DT?TEST

IDATA 0080H 007FH UNIT ?ID?TEST

IDATA 00FFH 0001H UNIT ?STACK

第一行顯示寄存器組0從地址0000H開(kāi)始，占用0008H個(gè)字節(jié)

第二行顯示DATA區(qū)變量從0008H開(kāi)始，占用0078H個(gè)字節(jié)

第三行顯示IDATA區(qū)變量從0080H開(kāi)始，占用007F個(gè)字節(jié)

第四行顯示堆棧從00FFH開(kāi)始，占0001H個(gè)字節(jié)

由于前面代碼中變量定義比較簡(jiǎn)單，且連續(xù)用完了所有空間，所以這里顯示比較簡(jiǎn)單

變量定義較多時(shí)，這里會(huì)有很多行

如果全局變量與局部變量分配不合理，就有可能出現(xiàn)類(lèi)似下面的行

0010H 0012H *** GAP ***

該行表示從0010H開(kāi)始連續(xù)0012H個(gè)字節(jié)未充分利用或根本未用到

出現(xiàn)這種情況最常見(jiàn)的原因是局變量太多、多個(gè)子程序中的局部變量數(shù)目差異太大、使用了寄存器切換但未充分利用。