實(shí)驗(yàn)一：

我定義一個(gè)結(jié)構(gòu)體：

typedef struct TestStruct

{

unsinged char Test1;

unsigned int Test2;

unsigned char Test3;

unsigned int Test4;

unsigned short Test5;

}TEST_STRUCT;

TEST_STRUCT TestStruct1;

然后我分別給這些成員都賦值，以便于在Memory里面觀察。

TestStruct1.Test1 = 0x11;

TestStruct1.Test2 = 0x22334455;

TestStruct1.Test3 = 0x66;

TestStruct1.Test4 = 0x778899AA;

TestStruct1.Test5 = 0xBBCC;

然后我調(diào)用了sizeof函數(shù)來計(jì)算這個(gè)結(jié)構(gòu)體的大小

sizeof(TestStruct1)

發(fā)現(xiàn)大小是20個(gè)Byte。而我原先預(yù)計(jì)的大小為1+4+1+4+2=12個(gè)Byte。

于是我利用AXD的內(nèi)存監(jiān)控查看了這段內(nèi)存的分配（Little Endian），如下：

0x01,0x00,0x00,0x00,0x55,0x44,0x33,0x22,0x66,0x00,0x00,0x00,0xAA,0x99,0x88,0x77

0xCC,0xBB,0x00,0x00

發(fā)現(xiàn)ARM在編譯的時(shí)候把原先不足Word長度的擴(kuò)展成了Word長度。

實(shí)驗(yàn)二：

后來想到，可能ARM這么做是為了不破壞結(jié)構(gòu)體的結(jié)構(gòu)。于是把結(jié)構(gòu)體改成了：

typedef struct TestStruct

{

unsinged char Test1;

unsigned char Test3;

unsigned short Test5;

unsigned int Test2;

unsigned int Test4;

}TEST_STRUCT;

再次調(diào)用sizeof，發(fā)現(xiàn)大小變成了12個(gè)Byte，符合了原先預(yù)計(jì)的大小。

再監(jiān)控內(nèi)存分配，如下：

0x01,0x06,0xCC,0xBB,0x55,0x44,0x33,0x22,0xAA,0x99,0x88,0x77

由此發(fā)現(xiàn)，原本松散的內(nèi)存變得如此的緊湊。

實(shí)驗(yàn)三：

隨后，又猜想，這樣是否真的可以縮小內(nèi)存損耗呢？ARM會(huì)不會(huì)在結(jié)構(gòu)體的中間插入別的變量呢。

于是做了一個(gè)實(shí)驗(yàn)，建立了三個(gè)BYTE大小的變量。

unsigned char TestData0 = 0xDD;

unsigned char TestData1 = 0xEE;

unsigned char TestData2 = 0xFF;

然后結(jié)構(gòu)體恢復(fù)成實(shí)驗(yàn)一的狀態(tài)，監(jiān)控了下內(nèi)存，發(fā)現(xiàn)變成了：

0x01,0x00,0x00,0x00,0x55,0x44,0x33,0x22,0x66,0x00,0x00,0x00,0xAA,0x99,0x88,0x77

0xCC,0xBB,0x00,0x00,0xDD,0xEE,0xFF

看來ARM并沒有在松散的結(jié)構(gòu)體中插入別的變量。

實(shí)驗(yàn)四：

利用了自己的一個(gè)大的工程，200K左右的RO以及80K左右的RW+ZI，做了一下優(yōu)化，發(fā)現(xiàn)效果明顯，RW+ZI縮減了不少。

最后，想到了ADS里面的編譯選項(xiàng)，三個(gè)級(jí)別的優(yōu)化以及For time/For spce選項(xiàng)都不能改變這個(gè)結(jié)果。

結(jié)論：（本文基于ARM7TDMI）

ARM中結(jié)構(gòu)體的成員的寫法可以決定最后的耗用內(nèi)存的大小，適當(dāng)?shù)膬?yōu)化可以節(jié)省大量寶貴的RAM。