實驗一：

我定義一個結構體：

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ù)來計算這個結構體的大小

sizeof(TestStruct1)

發(fā)現(xiàn)大小是20個Byte。而我原先預計的大小為1+4+1+4+2=12個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在編譯的時候把原先不足Word長度的擴展成了Word長度。

實驗二：

后來想到，可能ARM這么做是為了不破壞結構體的結構。于是把結構體改成了：

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個Byte，符合了原先預計的大小。

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

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

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

實驗三：

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

于是做了一個實驗，建立了三個BYTE大小的變量。

unsigned char TestData0 = 0xDD;

unsigned char TestData1 = 0xEE;

unsigned char TestData2 = 0xFF;

然后結構體恢復成實驗一的狀態(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并沒有在松散的結構體中插入別的變量。

實驗四：

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

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

結論：（本文基于ARM7TDMI）

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