ARM的字对齐问题总结

ARM的字对齐问题总结

一、啥是字对齐？为啥要字对齐？

现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问都可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特定的内存地址访问，这就是对齐。

字节对齐的原因大致是如下两条：

1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。

2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。

二、对齐规则

每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令

#pragma pack(n)，n=1,2,4,8,16来改变这一系数，其中的n就是你要指定的“对齐系数”。

规则：

1.数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行。

2.结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比较小的那个进行。

3.结合1、2可推断：第一、如果n大于等于该变量所占用的字节数，那么偏移量必须满足默认的对齐方式，第二、如果n小于该变量的类型所占用的字节数，那么偏移量为n的倍数，不用满足默认的对齐方式。

三、X86对齐实验

下面再简要回顾解释一下上述的对齐规则，结合实例进行分析：

1.数据类型自身的对齐值：对于char型数据，其自身对齐值为1字节，对于short型为2字节，对于int,float,double类型，其自身对齐值为4字节。

2.结构体的自身对齐值：其成员中自身对齐值最大的那个值。

3.指定对齐值：#pragma pack(n)来设定变量以n字节对齐方式。n字节对齐就是说变量存放的起始地址的偏移量有两种情况，第一、如果n大于等于该变量所占用的字节数，那么偏移量必须满足默认的对齐方式，第二、如果n小于该变量的类型所占用的字节数，那么偏移量为n的倍数，不用满足默认的对齐方式。

4.数据成员和结构体的有效对齐值：数据成员(数据类型)和数据结构的自身对齐值和指定对齐值中小的那个值，数据成员对齐了数据结构自然也就对齐了。

了解上述四个基本概念，我们开始讨论具体数据结构的成员和其自身的对齐方式。有效对齐值N是最终用来决定数据存放地址方式的值。有效对齐N，就是表示“对齐在N上”，也就是说该数据的"存放起始地址%N=0"。而数据结构中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是数据结构的起始地址。结构体的成员变量要对齐排放，结构体本身也要根据自身的有效对齐值圆整(结构体成员变量占用总长度需要是对结构体有效对齐值的整数倍)。下面结合VS2005中编译环境的例子进行深入了解：

例子B分析：

struct B

{

char b;

int a;

short c;

};

假设B从地址空间0x0000开始排放。该例中没有显式指定对齐值N，VS2005默认值为4。

成员变量b自身对齐值是1，比指定或默认指定对齐值4小，故有效对齐值为1，其存放地址0x0000符合0x0000%1=0，满足字节对齐原则。

成员变量a自身对齐值为4，和指定或默认指定对齐值4相等，故有效对齐值也为4，为了保证字节对齐，成员变量a只能存放在起始地址为0x0004到0x0007这四个连续的字节空间中，复核0x0004%4=0。

成员变量c自身对齐值为2，比指定或默认指定对齐值4小，故有效对齐值为2，可顺序存放在0x0008至0x0009两个字节空间中，符合0x0008%2=0。

至此满足了数据成员的字节对齐，接着看数据结构B的对齐。数据结构B的自身对齐值为其变量中最大对齐值(也就是成员变量b）4，故结构体B的有效对齐值也是4。根据结构体圆整的要求，0x0009到

0x0000=10字节，（10＋2）％4＝0。所以0x0000A到0x000B也为结构体B所占用。故B从0x0000到0x000B共有12个字节,sizeof(struct B)=12。

之所以在变量C补充2字节，是因为要实现编译器快速有效的存取结构数组,试想如果定义B结构数组,第一个结构起始地址是0没有问题,但是第二个结构呢?按照数组的定义,数组中所有元素都是紧挨着的,如果不把结构的大小补充为对齐值（4）的整数倍,那下一个结构的起始地址将是0x0000A,这显然不能满足结构的地址对齐了。

例子C分析：

/*指定按2字节对齐*/

__align(2)struct C

{

char b;

__packed是进行一字节对齐。

A、不能对packed的对象进行对齐；

B、所有对象的读写访问都进行非对齐访问；

C、float及包含float的结构联合及未用__packed的对象将不能字节对齐；

D、__packed对局部整形变量无影响；

D、强制由unpacked对象向packed对象转化是未定义,整形指针可以合法定

义为packed__packed int*p;//__packed int则没有意义。

3.__unaligned

用于修饰该变量可按照非对齐访问。

六、如何查找与字节对齐方面的问题

如果出现对齐或者赋值问题首先查看：

1.编译器的big little端设置；

2.看这种体系本身是否支持非对齐访问；

3.如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。

七、结论

针对于32位处理器对于本地使用的数据结构，为提高内存访问效率，采用四字节对齐方式；同时为了减少内存的开销，合理安排结构成员的位置，减少四字节对齐导致的成员之间的空隙，降低内存开销。

对于处理器之间的数据结构，需要保证消息的长度不因为在不同编译平台和不同处理器导致消息结构的长度发生变化，使用一字节对齐方式对消息结构进行紧缩；为保证处理器之间的消息的数据结构的内存访问效率，采用字节填充的方式自己对消息中成员进行四字节对齐。

数据结构的成员位置要兼顾成员之间的关系、数据访问效率和空间利用率。顺序安排的原则是：四字节的放在最前面，两字节的紧接最后一个四字节成员，一字节紧接最后一个两字节成员，填充字节放在最后。举例如下：

typedef struct tag_T_MSG{

long ParaA;

long ParaB;

short ParaC；

char ParaD;

char Pad;/*填充字节*/

}T_MSG;

ARM程序由于字节对齐引起的问题深入分析

首先说说，什么叫对齐。如果一个数据是从偶地址开始的连续存储，那么它就是半字对齐，否则就是非半字对齐；半字对齐的特征是bit0=0,其他位为任意值。字对齐的特征是bit1=0,bit0=1,其他位为任意值。如果一个数据是以能被4整除的地址开始的连续存储，那么它就是字对齐，否则就是非字对齐。举例说明四字节对齐：对内存进行操作时，被访问的地址必须为4的倍数。如果分配到的地址的地址不是4的倍数时，CPU实际访问的地址还是按照字对齐的方式来操作。也就是自动屏蔽bit1和bit0.

用ADS的ARM C Complier下Optimization Level可能引起问题，其中的一个问题就是字节对齐的问题。下面讲讲问题的现象及实质。

当时问题的现象是：程序使用一公共变量Buf创建队列，如果ADS编译优化选项采用Minium则软件工作正常；源码不变，如果采用ALL优化，则不正常，数据紊乱且无法工作。为了发现问题，我们分别用Minium和ALL编译，在反汇编条件下单步跟踪程序，观察CPU寄存器和内存变量的变化情况。发现在Minium模式下，编译器把队列内存块Uart0TxBuf分配到的地址是0x400015cc,这个地址是一个4字节对齐的地址，而在ALL模式下，编译器把Buf分配的地址是0x400015c2，这个地址是一个非4字节对齐的地址。正是由于这个非4字节对齐的地址导致了问题的发生。

问题发生在QueueCreate(void*Buf,uint32SizeOfBuf,uint8(*ReadEmpty)(),uint8(*WriteFull)())这个函数里，问题是如何发生的，

在了解问题发生的机理前，先了解QueueCreate这个函数的工作原理。QueueCreate工作原理是，首先把buf指向的内存初始化为DataQueue格式的结构体。DataQueue的结构体格式如下：

typedef struct{

QUEUE_DATA_TYPE*Out;/*指向数据输出位置*/

QUEUE_DATA_TYPE*In;/*指向数据输入位置*/

QUEUE_DATA_TYPE*End;/*指向Buf的结束位置*/

uint16NData;/*队列中数据个数*/

uint16MaxData;/*队列中允许存储的数据个数*/

uint8(*ReadEmpty)();/*读空处理函数*/

uint8(*WriteFull)();/*写满处理函数*/

QUEUE_DATA_TYPE*Buf;/*存储数据的空间*/

}DataQueue;

从结构体可以看出，结构体字节类型在内存分配为：4字节指针变量（*Out）、4字节指针变量（*In）、4字节指针变量（*End）、2字节变量NData、2字节变量MaxData、4字节函数指针变量ReadEmpty（）、4字节函数指针变量（WriteFull（））

观察结构体起始地址放在非对齐时会出现什么情况。

起始地址为0x400015c2时的由编译器分配得到的地址实际操作地址

*Out0x400015c2~0x400015c50x40015c0~0x400015c3

*In0x400014c6~0x400015c9x400014c4~0x400015c7

*End0x400015ca~0x400015cd0x400015c8~0x400015cb

从表中可以看出，实际操作的地址按照4字节对齐格式得到。例如，当执行*Out进行操作时，自动屏蔽bit1和bit0,因此实际发生变化的是0x40015c0~0x400015c3，而不是0x400015c2~0x400015c5，由于实际操作地址和编译器分配地址互相覆盖，当对*In操作时，会导致*Out一起变化，对*End操作时，*In也跟着变化。正是由于非对齐的原因导致创建队列和对列操作完全错误。

当内存起始地址为4字节对齐地址的情况时，编译器分配地址和实际地址一致，因此不存在上述问题。结论：

在ARM嵌入式系统中，当把一个内存区域初始化为某个结构体时，必须注意字节对齐的情况。如果该内存起始地址为非对齐地址，不仅得不到预期的结果，还可能导致一些很奇怪的让人无法理解表面问题。在C层面上不太容易观察到这些问题的实质，只有深入到汇编一层去分析程序，才可能理解这些现象的深层原因。

编译器不同在存放结构体方式可能不同，因此对齐也会有不同

ARM中字节对齐的深入探讨

ARM中字节对齐的深入探讨

阅读了yos的文章《内存对齐问题学习小结》，深有体会，看来在进行指针操作时，必须进行强制类型转换，否则可能出现预想不到的错误。

在我的一个项目中，需要进行数据包解码，同样出现数据对齐的问题，却没能找到好的解决方法问题如下

CPU ARM7，编译环境Keil RVCT3.0

#pragma pack(1)

typedef struct{

uint8u8a[3];

uint8u8b[4];

uint16u16c;

uint32u32d;

uint32u32e;

}TSTBLK,*PTSTBLK;

主程序

main

{

uint16i;

PTSTBLK pTST;

uint16u16k;

uint32u32m,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{

uint8u8a[3];

uint8u8b[4];

uint16u16c;

uint32u32d;

uint32u32e;

}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{

uint8u8b[4];

uint32u32d;

uint32u32e;

uint16u16c;

uint8u8a[3];

}TSTBLK,*PTSTBLK;

整个结构体仍然只占23个字节，但应该不会出现前面的问题。

__packed能解决问题

谢谢大家，用__packed可以解决问题，但我没理解__packed和#pragma pack(1)的区别，请问谁能再解释得清楚些？

我先前的实验结果确实是u32m=0x080B0A09u32l=0x0C0F0E0D

为什么不是0x0B0A0908和0x0F0E0D0C，原因不详

我不同意更改结构体，因为数据结构是规定死了，不能随意改

对于ARM CPU把结构体改为：

#pragma pack(1)

typedef struct{

uint8u8b[4];

uint32u32d;

uint32u32e;

uint16u16c;

uint8u8a[3];

}TSTBLK,*PTSTBLK;

uboot中，ARM体系下，设置变量4字节对齐

调试程序遇到由于buffer地址不是4字节对齐，所有底层去:

u32*p=(u32*)buf;

使得数据拷贝有误。所以，去参考了uboot中其他人的做法：

\board\s1845\flash.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-2009ARM Limited.All rights reserved.ARM DUI0348BC

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