序对齐问题的原因及举例说明...

DeepBlue @ 2007-09-07 09:40

 

因为今天和同事谈到了ARM平台下数据总线宽度及对齐方式对程序效率的影响问题
在定义结构数据类型时，为了提高系统效率，要注意字长对齐原则。
1．
先看下面的例子：
#include <iostream.h>
#pragma pack(4)
struct A
{
 char a;
 int  b;
};
#pragma pack()

#pragma pack(1)
struct B
{
 char a;
 int  b;
};
#pragma pack()

int main()
{
 
 A a;
 cout<<sizeof(a);   //8
 
 B b;
 cout<<sizeof(b);   //5
}

默认的vc我记得是4字节对齐，而ADS下是一字节对齐。
先谈PC下的对齐：
大家可以看到在ms的vc下按4字节对齐和1字节对齐的结果是截然不同的分别为8和5为什么会有这样的结果呢？这就是x86上字节对齐的作用。为了加快程序执行的速度，一些体系结构以对齐的方式设襁POST http://blog.ycul.com/post.php HTTP/1.0 D?长作为对齐边界。对于一些结构体变量，整个结构要对齐在内部成员变量最大的对齐边界，如A，整个结构以4为对齐边界，所以sizeof(a)为8，而不是5。
如果是原始我们概念下的的A中的成员将会一个挨一个存储 应该只有char+int只有5个字节这个差异就是由于对齐导致的显然我们可以看到 A的对齐要比B浪费3个字节的存储空间那为什么还要采取对齐呢？
那是因为体系结构的对齐和不对齐，是在时间和空间上的一个权衡。
字节对齐节省了时间。应该是设计者考虑用空间换取时间。
为什么说对齐会提高效率呢节省时间？我想大家要理解的重点之重点就在这里了
在我们常用的PC下总线宽度是32位
1.如果是总线宽度对齐的话
那么所有读写操作都是获取一个<=32位数据可以一次保证在数据总线传输完毕。没有任何的额外消耗。
|1|2|3|4|5|6|7|8|
从1开始这里是a的起始位置,5起始为b的位置 访问的时候
如果访问a一次在总线传输8位其他24位无效的
访问b时则一次在总线上传输32完成
读写均是一次完整
插说一下：读操作先要将读地址放到地址总线上然后下个时钟周期再从外部
存储器接口上读回数据通过数据总线返回需要两个周期
而写操作一次将地址及数据写入相应总线就完成了。
读操作要比写操作慢一半
 
2.我们看访问数据时如果不对齐地址的情况
|1|2|3|4|5|6|7|8|
此时a的地址没变还在1而因为是不对齐则b的位置就在2处
这时访问就带来效率上问题 访问a时没问题还是读会一个字节
但是2处地址因为不是总线宽度对齐一般的CPU在此地址操作将产生error
如sparc，MIPS。它们在硬件的设计上就强制性的要求对齐。在不对齐的地址上肯定发生错误。但是x86是支持非对齐访问的。

它通过多次访问来拼接得到的结果,具体做法就是从1地址处先读回后三字节234 暂存起来。然后再由5地址处读回一个字节5 与234进行拼接组成一个完整的int也就是b返回。
大家看看如此的操作带来的消耗多了不止三倍。很明显在字长对齐时效率要高许多。但然这种效率仅仅是访问多字节带来的。如果还是进行的byte操作那效率差不了多少。

嵌入式开发普遍比较重视性能，所以对齐的问题，有3种不同的处理方法：
1）有一种使用空间换时间做法是显式的插入reserved成员：
         struct A{
           char a;
           char reserved1[3];  //使用空间换时间
           int b;
           
}a;  ==>感觉此种编码方式比较专业，有显式提醒代码阅读者与维护者的功能...
2）随便怎么写，一切交给编译器自动对齐。
3）还有一种将逻辑相关的数据放在一起定义。

代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。下面举个例子：
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;

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