关于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中其他人的做法：

oards1845flash.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))

aligned类型属性指定类型的最低对齐要求。

Note

此类型属性是 ARM 编译器支持的 GNU 编译器扩展。

Copyright 2007-2009 ARM Limited. All rights reserved.	ARM DUI 0348BC
Non-Confidential, Unrestricted Access

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的通用性也解决不了办法。