ARM平臺的地址對齊問題

前言
ARM流行已久，做嵌入式開發(fā)的不知道ARM不大可能。鑒于其所具備的較低功耗下的較高性能，也就成了大多數嵌入式設備的首選了。
不過對于剛上手的人來說，有可能會遇到一些稀奇古怪的問題。畢竟大部分人都習慣了IA-32下的程序設計，雖然兩者都是32位的處理器，但是體系架構完全不同，于是也導致了一些隱含的問題。這里想描述一下一個有點蠱惑的問題，即在ARM上訪問非對齊地址內容，會出現所謂“不可預料”結果的問題。
ARM內存訪問的對齊問題
按照ARM文檔上的描述，其訪問規(guī)則如下：
1. 一次訪問4字節(jié)內容，該內容的起始地址必須是4字節(jié)對齊的位置上；
2. 一次訪問2字節(jié)內容，該內容的起始地址必須是2字節(jié)對齊的位置上；
（單字節(jié)的沒有這個問題，就不用考慮啦。 ）
好，既然規(guī)則如此，那應該遵守。不過么，不安分的人往往喜歡破壞規(guī)則，喜歡看看不遵守規(guī)則會有什么結果；另外么，即便遵規(guī)蹈距的人，有時也難免考慮不周，犯個錯也是正常現象。好，那么讓我們來看看犯錯的結果吧。例如下面的代碼：
char buff[8] = {0x12, 0x34, 0x56, 0x78, 0x9a, 0xab, 0xbc, 0xcd};
int v32, *p32;
short v16, *p16;
p32 = (int*)&( buff[1] ); //unalignment
p16 = (short*)&( buff[1] ); //unalignment
v32 = *p32; //what’s the result?
v16 = *p16; //what’s the result?
如果上面這段代碼在IA-32上運行，那么結果應該如下：
v32 = 0x9a785634
v16 = 0x5634
即便非對齊地址上訪問，IA-32也就是犧牲一點性能，但是結果保證是正確的。恩，這也是我們所期望的……
可是…… 換到ARM上呢？我們來看看在ADS1.2編譯后，執(zhí)行的結果如下：
v32 = 0x12785634
v16 = 0x1234
這個結果有點奇怪了吧。照理說指向0x34，那么如果是Big-Endian的話，v32應該是0x3456789a，如果是Little-Endian的話，就是前面IA-32的結果?？涩F在的結果呢？兩者都不是，莫名地把更低地址的0x12給湊進來了…… 而如果看看編譯生成的匯編code的話，這兩個賦值很簡單，分別用了ldr和ldrsh指令，指令沒有問題，分別用于讀取32位和16位數據，都是最基本的指令。嗯，嗯，這就是我們所要描述的訪問非對齊地址的問題了。
問題的緣由（個人猜測，非官方資料……）
個人感覺呢，這是ARM體系架構實現的問題，或者說這本來就是By Design的。這樣做簡化了處理器的實現，IA-32實現的時候肯定會對讀取地址是否對齊進行判斷，然后轉換為相應的操作 ，而ARM呢？沒有做這個事情，默認認為大家都按照規(guī)矩辦事，你要是膽敢破壞，俺就給你好看~~~
那有沒有辦法解決呢？
這個問題其實ARM自己也知道，所以呢，它在編譯器里面，已經添加了部分支持。不過有人會問，那上面那個情況呢？為什么結果還是不對呢？好像沒有添加什么支持嘛……
嗯，其實ARM是做了一定的努力的，只是這個情況它沒辦法解決…… 它做的事情就是：在編譯器能夠的得知的情況下，盡量保證訪問內容的正確。這句話有點籠統(tǒng)，那么把具體情況一個個來看看吧。
編譯器的努力（1）——所有局部/全局/靜態(tài)等變量都放在4字節(jié)對齊的地址上
其實這個努力很常見，由于在32位平臺上，一次訪問4字節(jié)是效率最高的，所以大多數32平臺的編譯器都如此處理，ARM的ADS也不例外。
編譯器的努力（2）——填充、填充、再填充
這個事情么，其實也是常見的。各類編譯器上，對于某些結構定義中會產生不對齊的情況，自動填充，以提高訪問效率（例如IA-32上訪問非對齊的，會加1個周期的）。而ARM的編譯器也一樣操作，不過感覺這里不單單是為了提高效率，也能夠順帶解決這個不對齊的問題。
編譯器的努力（3）——產生特殊代碼
嗯，這個就是關鍵了，也是ARM編譯器的與眾不同之處。先來看一段代碼：
__packed typedef struct _test
{
char a;
short c;
int d;
} test;
char buff[8] = {0x12, 0x34, 0x56, 0x78, 0x9a, 0xab, 0xbc, 0xcd};
test *p = (test *)buff;
v32 = p->d; //這里的v32借用上面的定義；
貌似多了個限定為__packed的struct，以此來造成不對齊的狀況，看不出多大區(qū)別嘛。可是運行一下的話，就會發(fā)現這里的結果是正確的。我們來看看ADS生成的匯編代碼吧。
v32 = q->d;
[0xe2890003] add r0,r9,#3
[0xeb000088] bl __rt_uread4
[0xe1a05000] mov r5,r0
看到這里的那條"bl __rt_uread4"的指令了吧。對ARM指令有一定了解的都知道bl其實就是一個函數調用。所以，這里的代碼其實是調用了ADS自己提供的__rt_uread4函數，該函數完成的操作就是讀取四個字節(jié)。ADS提供了類似的一系列函數，針對signed/unsigned，以及4字節(jié)/2字節(jié)的讀取/寫入操作。
估計看到這里，大家會問，如果沒有__packed限定符呢？猜對了，沒有__packed限定符，那么編譯器會對上面的情況pending，所以這個struct里面的d所在的位置是4字節(jié)對齊的（編譯期信息，而非實際運行期信息）。所以就回到類似最初的例子了。
那么，還有一種情況，就是在有__packed的情況下，而struct里的字段都是符合對齊要求的，那么生成的代碼會是怎么樣的呢？從實際生成的代碼來看，和上面的這段匯編代碼，唯一的區(qū)別就是第一條指令把#3改成了#4，而后面仍舊調用__rt_uread4函數。嗯，這樣結論就出來了：
編譯器會在使用__packed的情況下，自動對其中的4字節(jié)/2字節(jié)訪問添加特殊代碼，以保證其結果的正確。
好了，這個關于這個問題描述得差不多了，可能的話，盡量倚賴編譯器的這些功能，而對于編譯器無能為力的部分，就要靠萬分小心了……
p.s. 其實這里有很多事情可以來盡量預防此類問題，比如嵌入式項目往往喜歡自己管理內存分配，那么自己寫的內存分配函數就保證返回的地址都是4字節(jié)對齊位置上的……