平时大家接触最多的可能是X86平台，在这种系统上写程序几乎不需要考虑太多问题，但ARM上就不一样了，最常见也最容易被忽略的问题可能就是字节的对齐，即使像我这样有六七年程序开发经验的才手也时常难于提防，最近就有一个BUG，花了一天时间最终发现是对齐引发的，在此与大家分享，但愿大家能够注意到。
我在EBOOT中读取存在HARD DISK上的nk.bin文件，从而从HARD DISK上LOAD WINCE系统，在这个过程中总是有check sum错误，但从ethernet下载时不会有错，所以问题应该还是在我加的这部分代码上，而且同样的代码在PC上能正常运行。经过检查代码的逻辑关系是正确的。接着我在出错时将那些数据全部用调试信息打出来，发现从文件开始算起第4096个字节被丢掉了，而其它的字节都是对的。初步判断是对齐引发的问题，所以去查每一个BUFFER，最终发现是在读取硬盘数据时BUFFERR并没有按双字节对齐，而硬盘以16BIT读取数据，而引发了错误。
实际上，这类问题在ARM系统上很常见，让人防不胜防，以下是我的一些例子。
1，解析数据流时应该时刻注意。如果需要把一个数据流（BUFFER）转化成结构进行取值，就应该把这个结构定义为按字节存取.考虑如下结构：
struct a{
char a;
short b;
long c;
};
如果某个数据流中包含这样的结构，而且我们要直接将数据流的指针转化成该结构的指针，然后直接取结构成员的值，我们就应该将这个结构定义成按字节访问，即将其夹在语句
#pragma pack(push,1)
...
#pragma pack(pop)
之中。如果我们不这样做，编译器会将成员b的地址对齐到short指针的地址，即在a之后加上一个char即8位的成员，将C对齐到LONG，即在B之后再加一个char成员。如此一来，成员B和成员C就得不到正确的值了。
如果我们定义一个普通的结构用来存放一些数据，则不用定义成按字节存取，编译器会加上一些占位成员，但并不会影响程序的运行。从这个意义上讲，在ARM中，将结构成员定义成CHAR和SHORT来节约内存是没有意义的。
一个典型的例子就文件系统的驱动程序，文件是以一些已经定义好的结构存放在存储介质上的，它们被读取到一个BUFFER中，而具体取某个文件、目录结构时，我们会将地址转化成结构而读取其中的值。
2，访问外设时。
例如，磁盘驱动通常以16BIT的方式存取数据，即每次存取两个字节，这样就要求传给它的BUFFER是双字节对齐的，驱动程序应该至上层传来的指针做出正确的处理以保证数据的正确性。
3.有时，我们没有将数据流指针转化为结构指针取值，但如果我们读取的是双字节或者是四字节的数据，同样需要注意对齐的问题，例如，如果从一个BUFFER的偏移10处读取一个四字节值，则实际得到的值是偏移8处的
地址上的DWORD值。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Vichard/archive/2009/08/29/4497521.aspx