字对齐概念

一.什么是字节对齐,为什么要对齐?
　　现代计算机中内存空间都是按照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;
    PTSTBLK    pTST;

    uint16 u16k;
    uint32 u32m,u32l;
    uint8  DBUF[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 = 0x080B0A09   u32l = 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中其他人的做法：

/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-2009 ARM Limited. All rights reserved.ARM DUI 0348BCNon-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的通用性也解决不了办法。

 

======================================================================================

source： click here

一.什么是字节对齐,为什么要对齐?
   现代计算机中内存空间都是按照byte划分的，从理论上讲似乎对任何类型的变量的访问可以从任何地址开始，但实际情况是在访问特定类型变量的时候经常在特 定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序的一个接一个的排放，这就是对齐。
   对齐的作用和原因：各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。比如有些架构的CPU在访问 一个没有进行对齐的变量的时候会发生错误,那么在这种架构下编程必须保证字节对齐.其他平台可能没有这种情况，但是最常见的是如果不按照适合其平台要求对 数据存放进行对齐，会在存取效率上带来损失。比如有些平台每次读都是从偶地址开始，如果一个int型（假设为32位系统）如果存放在偶地址开始的地方，那 么一个读周期就可以读出这32bit，而如果存放在奇地址开始的地方，就需要2个读周期，并对两次读出的结果的高低字节进行拼凑才能得到该32bit数 据。显然在读取效率上下降很多。

二.字节对齐对程序的影响:
   先让我们看几个例子吧(32bit,x86环境,gcc编译器):
设结构体如下定义：
struct A
{
   int a;
   char b;
   short c;
};
struct B
{
   char b;
   int a;
   short c;
};
现在已知32位机器上各种数据类型的长度如下:
char:1(有符号无符号同)    
short:2(有符号无符号同)    
int:4(有符号无符号同)    
long:4(有符号无符号同)    
float:4    double:8
那么上面两个结构大小如何呢?
结果是:
sizeof(strcut A)值为8
sizeof(struct B)的值却是12

结构体A中包含了4字节长度的int一个，1字节长度的char一个和2字节长度的short型数据一个,B也一样;按理说A,B大小应该都是7字节。
之所以出现上面的结果是因为编译器要对数据成员在空间上进行对齐。上面是按照编译器的默认设置进行对齐的结果,那么我们是不是可以改变编译器的这种默认对齐设置呢,当然可以.例如:
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
   char b;
   int a;
   short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct C)值是8。
修改对齐值为1：
#pragma pack (1) /*指定按1字节对齐*/
struct D
{
   char b;
   int a;
   short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct D)值为7。
后面我们再讲解#pragma pack()的作用.

三.编译器是按照什么样的原则进行对齐的?
   先让我们看四个重要的基本概念：
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从地址空间0×0000开始排放。该例子中没有定义指定对齐值，在笔者环境下，该值默认为4。第一个成员变量b的自身对齐值是1，比指定或者默认指定 对齐值4小，所以其有效对齐值为1，所以其存放地址0×0000符合0×0000%1=0.第二个成员变量a，其自身对齐值为4，所以有效对齐值也为4， 所以只能存放在起始地址为0×0004到0×0007这四个连续的字节空间中，复核0×0004%4=0,且紧靠第一个变量。第三个变量c,自身对齐值为 2，所以有效对齐值也是2，可以存放在0×0008到0×0009这两个字节空间中，符合0×0008%2=0。所以从0×0000到0×0009存放的 都是B内容。再看数据结构B的自身对齐值为其变量中最大对齐值(这里是b）所以就是4，所以结构体的有效对齐值也是4。根据结构体圆整的要求， 0×0009到0×0000=10字节，（10＋2）％4＝0。所以0x0000A到0x000B也为结构体B所占用。故B从0×0000到0x000B 共有12个字节,sizeof(struct B)=12;其实如果就这一个就来说它已将满足字节对齐了, 因为它的起始地址是0,因此肯定是对齐的,之所以在后面补充2个字节,是因为编译器为了实现结构数组的存取效率,试想如果我们定义了一个结构B的数组,那 么第一个结构起始地址是0没有问题,但是第二个结构呢?按照数组的定义,数组中所有元素都是紧挨着的,如果我们不把结构的大小补充为4的整数倍,那么下一 个结构的起始地址将是0x0000A,这显然不能满足结构的地址对齐了,因此我们要把结构补充成有效对齐大小的整数倍.其实诸如:对于char型数据，其 自身对齐值为1，对于short型为2，对于int,float,double类型，其自身对齐值为4，这些已有类型的自身对齐值也是基于数组考虑的,只 是因为这些类型的长度已知了,所以他们的自身对齐值也就已知了.
同理,分析上面例子C：
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
   char b;
   int a;
   short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
第 一个变量b的自身对齐值为1，指定对齐值为2，所以，其有效对齐值为1，假设C从0×0000开始，那么b存放在0×0000，符合0×0000%1= 0;第二个变量，自身对齐值为4，指定对齐值为2，所以有效对齐值为2，所以顺序存放在0×0002、0×0003、0×0004、0×0005四个连续 字节中，符合0×0002%2=0。第三个变量c的自身对齐值为2，所以有效对齐值为2，顺序存放
在0×0006、0×0007中，符合 0×0006%2=0。所以从0×0000到0×00007共八字节存放的是C的变量。又C的自身对齐值为4，所以C的有效对齐值为2。又8%2=0,C 只占用0×0000到0×0007的八个字节。所以sizeof(struct C)=8.

四.如何修改编译器的默认对齐值?
1.在VC IDE中，可以这样修改：[Project]|[Settings],c/c++选项卡Category的Code Generation选项的Struct Member Alignment中修改，默认是8字节。
2.在编码时，可以这样动态修改：#pragma pack .注意:是pragma而不是progma.

五.针对字节对齐,我们在编程中如何考虑?

   如果在编程的时候要考虑节约空间的话,那么我们只需要假定结构的首地址是0,然后各个变量按照上面的原则进行排列即可,基本的原则就是把结构中的变量按照 类型大小从小到大声明,尽量减少中间的填补空间.还有一种就是为了以空间换取时间的效率,我们显示的进行填补空间进行对齐,比如:有一种使用空间换时间做 法是显式的插入reserved成员：
        struct A{
          char a;
          char reserved[3];//使用空间换时间
          int b;
}

reserved成员对我们的程序没有什么意义,它只是起到填补空间以达到字节对齐的目的,当然即使不加这个成员通常编译器也会给我们自动填补对齐,我们自己加上它只是起到显式的提醒作用.

六.字节对齐可能带来的隐患:
   代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。例如：
unsigned int i = 0×12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;

p=&i;
*p=0×00;
p1=(unsigned short *)(p+1);
*p1=0×0000;
最后两句代码，从奇数边界去访问unsignedshort型变量，显然不符合对齐的规定。
在x86上，类似的操作只会影响效率，但是在MIPS或者sparc上，可能就是一个error,因为它们要求必须字节对齐.

七.如何查找与字节对齐方面的问题:
如果出现对齐或者赋值问题首先查看
1. 编译器的big little端设置
2. 看这种体系本身是否支持非对齐访问
3. 如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。

八.相关文章:转自http://blog.csdn.net/goodluckyxl/archive/2005/10/17/506827.aspx

ARM下的对齐处理
from DUI0067D_ADS1_2_CompLib

3.13 type  qulifiers

有部分摘自ARM编译器文档对齐部分

对齐的使用:
1.__align(num)
  这个用于修改最高级别对象的字节边界。在汇编中使用LDRD或者STRD时
  就要用到此命令__align(8)进行修饰限制。来保证数据对象是相应对齐。
  这个修饰对象的命令最大是8个字节限制,可以让2字节的对象进行4字节
  对齐,但是不能让4字节的对象2字节对齐。
  __align是存储类修改,他只修饰最高级类型对象不能用于结构或者函数对象。
 
2.__packed
 __packed是进行一字节对齐
 1.不能对packed的对象进行对齐
 2.所有对象的读写访问都进行非对齐访问
 3.float及包含float的结构联合及未用__packed的对象将不能字节对齐
 4.__packed对局部整形变量无影响
 5.强制由unpacked对象向packed对象转化是未定义,整形指针可以合法定
 义为packed。
    __packed int* p;  //__packed int 则没有意义
 6.对齐或非对齐读写访问带来问题
 __packed struct STRUCT_TEST
{
 char a;
 int b;
 char c;
}  ;    //定义如下结构此时b的起始地址一定是不对齐的
        //在栈中访问b可能有问题,因为栈上数据肯定是对齐访问[from CL]
//将下面变量定义成全局静态不在栈上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
__packed int* q;  //此时定义成__packed来修饰当前q指向为非对齐的数据地址下面的访问则可以

p = (char*)&a;          
q = (int*)(p+1);      

*q = 0×87654321;
/*  
得到赋值的汇编指令很清楚
ldr      r5,0×20001590 ; = #0×12345678
[0xe1a00005]   mov      r0,r5
[0xeb0000b0]   bl       __rt_uwrite4  //在此处调用一个写4byte的操作函数
     
[0xe5c10000]   strb     r0,[r1,#0]   //函数进行4次strb操作然后返回保证了数据正确的访问
[0xe1a02420]   mov      r2,r0,lsr #8
[0xe5c12001]   strb     r2,[r1,#1]
[0xe1a02820]   mov      r2,r0,lsr #16
[0xe5c12002]   strb     r2,[r1,#2]
[0xe1a02c20]   mov      r2,r0,lsr #24
[0xe5c12003]   strb     r2,[r1,#3]
[0xe1a0f00e]   mov      pc,r14
*/

/*
如果q没有加__packed修饰则汇编出来指令是这样直接会导致奇地址处访问失败
[0xe59f2018]   ldr      r2,0×20001594 ; = #0×87654321
[0xe5812000]   str      r2,[r1,#0]
*/

//这样可以很清楚的看到非对齐访问是如何产生错误的
//以及如何消除非对齐访问带来问题
//也可以看到非对齐访问和对齐访问的指令差异导致效率问题
}