關于arm 的字節對齊

　　現代計算機中內存空間都是按照byte劃分的，從理論上講似乎對任何類型的變量的訪問可以從任何地址開始，但實際情況是在訪問特定類型變量的時候經常在特定的內存地址訪問，這就需要各種類型數據按照一定的規則在空間上排列，而不是順序的一個接一個的排放，這就是對齊。
　　對齊的作用和原因：各個硬件平臺對存儲空間的處理上有很大的不同。一些平臺對某些特定類型的數據只能從某些特定地址開始存取。比如有些架構的CPU在訪問一個沒有進行對齊的變量的時候會發生錯誤,那么在這種架構下編程必須保證字節對齊.其他平臺可能沒有這種情況，但是最常見的是如果不按照適合其平臺要求對數據存放進行對齊，會在存取效率上帶來損失。比如有些平臺每次讀都是從偶地址開始，如果一個int型（假設為32位系統）如果存放在偶地址開始的地方，那么一個讀周期就可以讀出這32bit，而如果存放在奇地址開始的地方，就需要2個讀周期，并對兩次讀出的結果的高低字節進行拼湊才能得到該32bit數據。顯然在讀取效率上下降很多。

二.編譯器是按照什么樣的原則進行對齊的?
　　先讓我們看四個重要的基本概念：
　　1.數據類型自身的對齊值：對于char型數據，其自身對齊值為1，對于short型為2，對于int,float,double類型，其自身對齊值為4，單位字節。
　　2.結構體的自身對齊值：其成員中自身對齊值最大的那個值。
　　3.指定對齊值：#pragma pack (value)時的指定對齊值value。
　　4.數據成員和結構體的有效對齊值：數據成員(數據類型)和數據結構的自身對齊值和指定對齊值中小的那個值。(數據成員對齊了數據結構自然也就對齊了)
　　有了這些值，我們就可以很方便的來討論具體數據結構的成員和其自身的對齊方式。有效對齊值N是最終用來決定數據存放地址方式的值，最重要。有效對齊N，就是表示“對齊在N上”，也就是說該數據的"存放起始地址%N=0".而數據結構中的數據變量都是按定義的先后順序來排放的。第一個數據變量的起始地址就是數據結構的起始地址。結構體的成員變量要對齊排放，結構體本身也要根據自身的有效對齊值圓整(就是結構體成員變量占用總長度需要是對結構體有效對齊值的整數倍，結合下面例子理解)。這樣就不難理解上面的幾個例子的值了。

例子分析：
分析例子B；
struct B
{
char b;
int a;
short c;
};

　　假設B從地址空間0x0000開始排放。該例子中沒有定義指定對齊值，在筆者環境下，該值默認為4。第一個成員變量b的自身對齊值是1，比指定或者默認指定對齊值4小，所以其有效對齊值為1，所以其存放地址0x0000符合0x0000%1=0.第二個成員變量a，其自身對齊值為4，所以有效對齊值也為4，所以只能存放在起始地址為0x0004到0x0007這四個連續的字節空間中，復核0x0004%4=0,且緊靠第一個變量。第三個變量c,自身對齊值為 2，所以有效對齊值也是2，可以存放在0x0008到0x0009這兩個字節空間中，符合0x0008%2=0。所以從0x0000到0x0009存放的都是B內容。再看數據結構B的自身對齊值為其變量中最大對齊值(這里是b）所以就是4，所以結構體的有效對齊值也是4。根據結構體圓整的要求， 0x0009到0x0000=10字節，（10＋2）％4＝0。所以0x0000A到0x000B也為結構體B所占用。故B從0x0000到0x000B 共有12個字節,sizeof(struct B)=12;其實如果就這一個就來說它已將滿足字節對齊了, 因為它的起始地址是0,因此肯定是對齊的,之所以在后面補充2個字節,是因為編譯器為了實現結構數組的存取效率,試想如果我們定義了一個結構B的數組,那么第一個結構起始地址是0沒有問題,但是第二個結構呢?按照數組的定義,數組中所有元素都是緊挨著的,如果我們不把結構的大小補充為4的整數倍,那么下一個結構的起始地址將是0x0000A,這顯然不能滿足結構的地址對齊了,因此我們要把結構補充成有效對齊大小的整數倍.其實諸如:對于char型數據，其自身對齊值為1，對于short型為2，對于int,float,double類型，其自身對齊值為4，這些已有類型的自身對齊值也是基于數組考慮的,只是因為這些類型的長度已知了,所以他們的自身對齊值也就已知了.
同理,分析上面例子C：

__align(2) struct C
{
char b;
int a;
short c;
};*取消指定對齊，恢復缺省對齊*

　　第一個變量b的自身對齊值為1，指定對齊值為2，所以，其有效對齊值為1，假設C從0x0000開始，那么b存放在0x0000，符合0x0000%1= 0;第二個變量，自身對齊值為4，指定對齊值為2，所以有效對齊值為2，所以順序存放在0x0002、0x0003、0x0004、0x0005四個連續字節中，符合0x0002%2=0。第三個變量c的自身對齊值為2，所以有效對齊值為2，順序存放
在0x0006、0x0007中，符合 0x0006%2=0。所以從0x0000到0x00007共八字節存放的是C的變量。又C的自身對齊值為4，所以C的有效對齊值為2。又8%2=0,C 只占用0x0000到0x0007的八個字節。所以sizeof(struct C)=8.

三.在ADS編譯器中的實例.
#pragma pack(push) //保存對齊狀態
//設定為4字節對齊
__align(4) struct test
{
char m1;
double m4;
int m3;
};
　　以上結構的大小為16，下面分析其存儲情況，首先為m1分配空間，其偏移量為0，滿足我們自己設定的對齊方式（4字節對齊），m1占用1個字節。接著開始為m4分配空間，這時其偏移量為1，需要補足3個字節，這樣使偏移量滿足為n=4的倍數（因為sizeof(double)大于n）,m4占用8個字節。接著為m3分配空間，這時其偏移量為12，滿足為4的倍數，m3占用4個字節。這時已經為所有成員變量分配了空間，共分配了16個字節，滿足為n的倍數。如果把上面的 __align(4) struct test 改為 __align(16) struct test ，那么我們可以得到結構的大小為24。
=========
編譯器不同在存放結構體方式可能不同，因此對齊也會有不同

ARM中字節對齊的深入探討

ARM中字節對齊的深入探討
閱讀了yos的文章《內存對齊問題學習小結》，深有體會，看來在進行指針操作時，必須進行強制類型轉換，否則可能出現預想不到的錯誤。

在我的一個項目中，需要進行數據包解碼，同樣出現數據對齊的問題，卻沒能找到好的解決方法問題如下
CPU ARM7 ，編譯環境 Keil RVCT3.0

#pragma pack(1)
typedef struct {
uint8 u8a[3];
uint8 u8b[4];
uint16 u16c;
uint32 u32d;
uint32 u32e;
} TSTBLK,* PTSTBLK;

主程序
main
{
uint16 i;
PTSTBLKpTST;

uint16 u16k;
uint32 u32m,u32l;
uint8DBUF[200]；

for(i= 0 ;i<200;i++)DBUF[i]=i;

pTST=(PTSTBLK)DBUF;// 1
u16k = (pTST->u16c);// 2
u32m = pTST->u32d;// 3
u32l = pTST->u32e;// 4
//以下語句是避免 u16k,u32m,u32l被優化掉
i = u16k;
i = (uint16)u32m;
i = (uint16)u32l;
}

運行語句1 后， 結構體中的
u8a[] = 0x00~0x02
u8a[] = 0x03~0x06
u16c = 0x0807
u32d = 0x0C0B0A09
u32e = 0x100F0E0D
顯然以上結果是我們所需要的，正確！
但繼續運行 2,3,4得到
u16k = 0x0706
u32m = 0x080B0A09
u32l = 0x0C0F0E0D
字節對齊發生了問題，亂了！
亂得還不輕 u32m 沒有等于0x0B0A0908
u32m 沒有等于0x0B0A0908
u32m 也沒有等于0x0F0E0D0C
why?

我試圖用u16k = (uint16)(pTST->u16c);
u32m = (uint32)pTST->u32d;
去修改，但無效！
其實pTST->u16c本身就是16位的，強制轉到16位自然沒有任何意義。

你說的情況對于ARM CPU確實存在，但對于其它體系結構就不會出現
這是一個典型的ARM非對齊訪問的問題。#pragma pack(1)能保證你的結構體中的數據是緊縮對齊的（在內存中是依次排列的）。那么對于
#pragma pack(1)
typedef struct {
uint8 u8a[3];
uint8 u8b[4];
uint16 u16c;
uint32 u32d;
uint32 u32e;
} TSTBLK,* PTSTBLK;
假設該結構體存放的基地址為0,則u8a[3]位于0－2字節, u8b[4]位于3－6字節，u16c位于7－8字節，依次類推。那么當我們去訪問u16c時編譯器會編譯成一條訪問地址為7的半字讀的匯編語言，而地址為7對于半字讀來說是一個非對齊訪問，CPU就自動會把地址變成把最低位忽略，也是說CPU讀的實際地址為6,于是讀u16c得到的是6 、7兩個字節即u16c=0x0706。對于字的訪問CPU會忽略低兩位地址，分析方法與前相同。你的兩個32位數我不能理解，你怎么可能得到那樣的結果，是不是寫錯了哦？？我覺得你應該分別得到0x0B0A0908 0x0F0E0D0C才對。當然還涉及一個字節序的問題。
這一個問題在ARM CPU中會出現，但對于POWERPC的CPU或X86的CPU你的代碼就不會出現問題，這都是CPU對非對齊訪問采用的處理方式不同造成，POWERPC X86 會把非半字的非對齊訪問變成兩個字節訪問，因為不會出現上面問題。MIPS我沒有去研究過。
對于ARM CPU把結構體改為：
#pragma pack(1)
typedef struct {
uint8 u8b[4];
uint32 u32d;
uint32 u32e;
uint16 u16c;
uint8 u8a[3];
} TSTBLK,* PTSTBLK;
整個結構體仍然只占23個字節，但應該不會出現前面的問題。

__packed 能解決問題
謝謝大家，用__packed 可以解決問題，但我沒理解__packed 和#pragma pack(1)的區別，請問誰能再解釋得清楚些？

我先前的實驗結果確實是 u32m = 0x080B0A09u32l = 0x0C0F0E0D
為什么不是0x0B0A0908 和0x0F0E0D0C，原因不詳

我不同意更改結構體，因為數據結構是規定死了，不能隨意改
對于ARM CPU把結構體改為：
#pragma pack(1)
typedef struct {
uint8 u8b[4];
uint32 u32d;
uint32 u32e;
uint16 u16c;
uint8 u8a[3];
} TSTBLK,* PTSTBLK;

uboot中，ARM體系下，設置變量4字節對齊

調試程序遇到由于buffer地址不是4字節對齊，所有底層去:

u32 *p =(u32 *)buf;

使得數據拷貝有誤。所以，去參考了uboot中其他人的做法：

boards1845flash.c中的：

#define __align__ __attribute__ ((aligned (8)))
static __align__ ulong precmd0[2]= { 0x00aa00aa, 0x00aa00aa };

所以，此處就可以這么做，使一個字符數組變量4字節對齊的：

static__attribute__ ((aligned (4)))unsigned char data_buf[MAX_PAGE_SIZE];

ARM 的 RealView中的解釋：

4.4.2.__attribute__((aligned))

4.5.3 __attribute__((aligned))
aligned 變量屬性指定變量或結構字段的最低對齊要求（按字節計算）。
注意
此變量屬性是 ARM 編譯器支持的 GNU 編譯器擴展。
示例
int Variable_Attributes_aligned_0 __attribute__ ((aligned (16)));

short Variable_Attributes_aligned_1[3] __attribute__ ((aligned));

2.1.157 --unaligned_access, --no_unaligned_access
此選項啟用或禁用基于 ARM 體系結構的處理器上的未對齊數據訪問。
缺省設置
對于支持未對齊數據訪問的基于 ARM 體系結構的處理器，缺省為
--unaligned_access。這包括：
• 基于 ARMv6 體系結構的所有處理器
• 基于 ARMv7-A 和 ARMv7-R 體系結構的處理器。
對于不支持未對齊數據訪問的基于 ARM 體系結構的處理器，缺省為
--no_unaligned_access。這包括：
• 基于 ARMv6 以前版本的體系結構的所有處理器
• 基于 ARMv7-M 體系結構的處理器。
用法
--unaligned_access
在支持未對齊數據訪問的處理器（如 --cpu=ARM1136J-S）上使用
--unaligned_access 可加快對壓縮結構的訪問速度。
若要啟用未對齊支持，必須執行下列操作：
• 在初始化代碼中清除 CP15 寄存器 1 的 A 位（即位 1）。
• 在初始化代碼中設置 CP15 寄存器 1 的 U 位（即位 22）。
U 位的初始值由內核的 UBITINIT 輸入確定。
RVCT 庫包含旨在利用未對齊訪問的某些庫函數的特殊版本。在啟
用未對齊訪問支持的情況下，RVCT 工具將使用這些庫函數從未對
齊訪問中獲益。
--no_unaligned_access
使用 --no_unaligned_access 可在 ARMv6 處理器上禁止生成未對齊
字和半字訪問。
若要在不使用未對齊訪問的情況下在 ARMv6 目標上啟用對四字節
求模的對齊檢查，必須執行下列操作：
• 在初始化代碼中設置 CP15 寄存器 1 的 A 位（即位 1）。
• 在初始化代碼中設置 CP15 寄存器 1 的 U 位（即位 22）。
U 位的初始值由內核的 UBITINIT 輸入確定。

注意
ARM 處理器內核不支持未對齊雙字訪問，例如對 long long 整數的
未對齊訪問。雙字訪問必須是八字節或四字節對齊的。
編譯器不支持對八字節求模的對齊檢查。也就是說，編譯器（或
更具體地說是 RVCT 工具集）不支持 CP15 寄存器 1 中的配置 U =
0、A = 1。
RVCT 庫包含旨在利用未對齊訪問的某些庫函數的特殊版本。若要
在禁用未對齊訪問支持的情況下禁止使用這些高級庫函數，則在
編譯 C 和 C++ 源文件以及匯編語言源文件組合的情況下，需要同
時在編譯器命令行和匯編器命令行中指定 --no_unaligned_access。

限制
僅當軟件中的對齊支持選項與處理器內核中的對齊支持選項相匹配時，針對支
持未對齊數據訪問的處理器而編譯的代碼才能正確運行。

2。GNU C 擴展之__attribute__ 機制簡介

aligned (alignment)
該屬性規定變量或結構體成員的最小的對齊格式，以字節為單位。例如：

int x __attribute__ ((aligned (16))) = 0; 編譯器將以16字節（注意是字節byte不是位bit）對齊的方式分配一個變量。也可以對結構體成員變量設置該屬性，例如，創建一個雙字對齊的int對，可以這么寫：

struct foo { int x[2] __attribute__ ((aligned (8))); }; 如上所述，你可以手動指定對齊的格式，同樣，你也可以使用默認的對齊方式。如果aligned后面不緊跟一個指定的數字值，那么編譯器將依據你的目標機器情況使用最大最有益的對齊方式。例如：

short array[3] __attribute__ ((aligned)); 選擇針對目標機器最大的對齊方式，可以提高拷貝操作的效率。
aligned屬性使被設置的對象占用更多的空間，相反的，使用packed可以減小對象占用的空間。
需要注意的是，attribute屬性的效力與你的連接器也有關，如果你的連接器最大只支持16字節對齊，那么你此時定義32字節對齊也是無濟于事的。
packed
使用該屬性可以使得變量或者結構體成員使用最小的對齊方式，即對變量是一字節對齊，對域（field）是位對齊。
下面的例子中，x成員變量使用了該屬性，則其值將緊放置在a的后面：

struct test{char a;int x[2] __attribute__ ((packed));};

3.關于ARM-GCC的ALIGN問題

最后在CSDN上查到arm-linux-gcc的方法（以下是引用）：

1.在makefile里加-fpack-struct 選項,這樣的話對所有的結構按一字節對齊.

不得不說,確實有那么些質量較差的程序可能需要你部分自然對齊,部分一字 節對齊,此時

2. typedef struct pack{

}__attribute__((packed))

可利用__attribute__屬性

由此可見對齊的參數是與平臺相關的，gcc的通用性也解決不了辦法。