我搜到一篇帖子，恩，是说靠编译器。
http://blog.csdn.net/alenwelkin/archive/2006/12/19/1448324.aspx

有些arm有byte, half word, word传输指令。
如果遇到不对齐的编译情况，编译器可以用byte, half word构造一个unaligned word

对齐不是单纯由计算机硬件决定的，而是CPU和编译器共同处理的结果。编译器可以把较长数据的访问拆分成多个byte来构造。
在计算机设计里面，这只不过是一种接口的设计抉择： 对齐既可以如X86那样处于接口之下，也可以暴露在接口之上由编译器完成。如同float point一样。

arm的编译器可以检查到所有未对齐情况？
比如：


运行没有问题？编译器把这种情况处理了？
如果是的话，arm没有未对齐异常哦？

char buf[10];
int *p = (int *)&buf[1];
*p = 10;
这段程序在ARM cpu平台上运行一般是有问题的。

恩，我刚才搜到一篇文章，unaligned access在ARM上引发的是一个data-abort exception
http://www.embedded.com/192202641?_requestid=462050

会，比如参数需要一个word pointer，而传入一个unaligned word pointer，这个时候就没办法构造了。比如上面传*str给printf

看来ARM平台处理器繁多，各自还不一样。
我搜到的是会触发异常的。

arm4以后的，配合gcc3.x以上一般来说没有问题，之前的我没有平台和编译器，无法尝试。
以前我专门处理过arm的对齐问题，所以记得很清楚。

risc和编译器的相关度比cisc大得多。为了保持设计的简洁，大量cisc由硬件搭建的硬电路功能，放到硬软接口之外，依赖软件配合实现（比如上边说的对齐之类的东西，这里就是指编译器，当然，软件不可能解决所有硬件问题，就像*str没办法拆出来一样，其中一个原因归咎于编译器系统的现有水平还不能达到我们预期的期望，未来的编译器怎样，就不好说了。）
所以一个高效的risc处理器，需要一个强大的编译器。两个比较显示的例子，一个是DSP,一个是VLIW。
VLIW是一个处理能力强大的东西，但是发展还不是很好，一个重要原因是它缺乏一个强大到可以支撑它的编译系统。

至于arm...估计都差不多吧，呵呵，我是没有条件用完所有的arm.

[ 本帖最后由 gvim 于 2008-5-19 17:58 编辑 ]

直至ARMV5TE，ARM体系结构都不支持边界不对齐的指针。