啊，網路真強大，果然讓我找到答案了！

 在ARM core的平臺(StrongARM, 2410, XScale)上，如果企圖通過一個獨立的指標對某個數
據結構的內部成員域進行定位和訪問時，會遇到下面的問題(注，在IA-32 X86平臺不會出現
這樣的問題)。

定義一個數據結構：
struct __attribute__((packed)) test {
char c; // 1個位元組
short s; // 2個位元組
long l; // 4個位元組
} st;

packed屬性，對應於gcc編譯選項 -fpack-struct；

test的記憶體佈局在該屬性的制約下是緊湊的，也就意味著第2、3個成員s、l的起始地址將是
奇地址。

如果另行定義一個獨立指標： unsigned long t;
通過“t+偏移位元組數”的方式來定位(訪問)結構內成員域，則會在強制型別轉換t指標來賦值
或者讀取相應成員域時，出現下面的問題：
(假定該結構的起始地址為A0, 則c、s、l的地址各為A0、A1、A3)

1. 編譯器版本(arm version)：GCC 2.95.2 / 3.2 / 3.3.2
t = (unsigned long) &st;
*((short*)(t+1)) = 0x0201;
期望: 0x01賦於A1位元組, 0x02賦於A2位元組
實際: 0x01賦於A0位元組, 0x02賦於A1位元組，與期望不吻合

*((long*)(t+3)) = 0x08070605;
期望: 0x05 - 0x08 逐次賦於 A3 - A6 位元組
實際: 0x05 - 0x08 逐次賦於 A0 - A3 位元組，與期望不吻合

結論： 基於這些GCC版本，如果對奇地址進行強制型別轉換，企圖獲得"字、雙字"的資料型別，
則強制轉換後所獲得的資料型別，其地址將被自動"優化"為最近的可被相應對齊模數
(字型資料的對齊模數是2，雙字的是4)整除的低位偶地址！

2. 編譯器版本(arm version)：GCC 2.95.3 / 3.0
t = (unsigned long) &st;
*((short*)(t+1)) = 0x0201;
期望: 0x01賦於A1位元組, 0x02賦於A2位元組
實際: 0x01賦於A1位元組, 0x02賦於A2位元組，與期望吻合

*((long*)(t+3)) = 0x08070605;
期望: 0x05 - 0x08 逐次賦於 A3 - A6 位元組
實際: 0x05 - 0x08 逐次賦於 A0 - A3 位元組，與期望不吻合

結論： 基於這些GCC版本，如果對奇地址進行強制型別轉換，企圖獲得"雙字"的資料型別，
則強制轉換後所獲得的資料型別，其地址將被自動"優化"為最近的可被相應對齊模數
4整除的低位偶地址！但對字型資料的此類操作，卻不會引起這種指標優化。


附，有資料稱：
某些架構上訪問資料時有對齊的要求，比如只能從4位元組邊界上讀取一個4位元組的資料型別。
IA-32架構沒有硬性要求對齊，儘管未對齊的訪問降低執行效率。另外一些架構，比如MIPS、
SPARC、m68k、ARM(<V3)，要求對齊訪問，否則向當前程序分發SIGBUS訊號，主要是相對早
期的RISC CPU存在此問題。

那麼有沒有一個辦法(比如gcc的編譯選項，或者一個__attribute__)，能制約上述的這種指標優化，
使其不自動發生！從而使實際操作與期望操作相吻合？

進一步地問，為何不同版本的arm-linux-gcc所編譯出的執行碼的在這個問題上的表現不一樣！？
這後面有更深層的理論背景嗎？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如果endian是確定的，我喜歡這樣的形式：((unsigned char*)&s)[0] * 256 + ((unsigned char*)&s)[1] 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
en，這樣把操作分解成基於位元組的處理確實是一個變通的辦法，和本人的考慮是一致的；在找不出更好解決方法的情況下，我認為可以有下面3種辦法來回避這樣的問題：
1. 改變資料來源的結構佈局，放棄緊湊佈局；
代價：增加並浪費了 padding 位元組，且既有應用需要重寫，以配合結構體記憶體佈局的變化；
2. 改變對結構成員的訪問方式，放棄通過獨立指標來定位/讀寫成員域，而直接採用成員名的方式訪問；
代價：既有應用程式的改動範圍較大；
3. 維持目前的資料來源和資料訪問方式，而新增一個過渡層，表現形式可以是一組巨集，或者行內函數，或
者函式，對結構體內的一切字或雙字型資料的訪問，通過這個過渡邏輯被分拆為以位元組為基礎的操作，
從而回避指標強制型別轉換時發生優化；這也同樣是nxin的思路！
代價：既有應用程式在訪問結構體成員時的程式碼形式發生變化，但個人認為這種方法對系統整體程式碼的
影響是最小的。

可是變通歸變通，歡迎大家繼續對可能根本解決此問題的方法進行討論！謝謝！