ARM盛行已久，做嵌入式开发的不知道ARM不大或许。鉴于其所具有的较低功耗下的较高功用，也就成了大多数嵌入式设备的首选
不过关于刚上手的人来说，有或许会遇到一些八怪七喇的问题。究竟大部分人都习惯了IA-32下的程序设计，尽管两者都是32位的
构彻底不同，所以也导致了一些隐含的问题。这儿想描绘一下一个有点迷惑的问题，即在ARM上拜访非对齐地址内容，会呈现所
问题。
ARM内存拜访的对齐问题
依照ARM文档上的描绘，其拜访规则如下：
1. 一次拜访4字节内容，该内容的开始地址有必要是4字节对齐的方位上；
2. 一次拜访2字节内容，该内容的开始地址有必要是2字节对齐的方位上；
（单字节的没有这个问题，就不必考虑啦。 ）
好，已然规则如此，那应该恪守。不过么，不安分的人往往喜爱损坏规则，喜爱看看不恪守规则会有什么成果；别的么，即使遵
免考虑不周，犯个错也是正常现象。好，那么让咱们来看看犯错的成果吧。例如下面的代码：
char buff[8] = {0x12, 0x34, 0x56, 0x78, 0x9a, 0xab, 0xbc, 0xcd};
int v32, *p32;
short v16, *p16;
p32 = (int*)&( buff[1] ); //unalignment
p16 = (short*)&( buff[1] ); //unalignment
v32 = *p32; //what’s the result?
v16 = *p16; //what’s the result?
假如上面这段代码在IA-32上运转，那么成果应该如下：
v32 = 0x9a785634
v16 = 0x5634
即使非对齐地址上拜访，IA-32也便是献身一点功用，但是成果确保是正确的。恩，这也是咱们所希望的……
但是…… 换到ARM上呢？咱们来看看在ADS1.2编译后，履行的成果如下：
v32 = 0x12785634
v16 = 0x1234
这个成果有点古怪了吧。照理说指向0x34，那么假如是Big-Endian的话，v32应该是0x3456789a，假如是Little-Endian的话，便是前面
可现在的成果呢？两者都不是，莫名地把更低地址的0x12给凑进来了…… 而假如看看编译生成的汇编code的话，这两个赋值很
ldrsh指令，指令没有问题，别离用于读取32位和16位数据，都是最基本的指令。嗯，嗯，这便是咱们所要描绘的拜访非对齐地址的
问题的缘由（个人猜想，非官方材料……）
个人感觉呢，这是ARM系统架构完结的问题，或者说这本来便是By Design的。这样做简化了处理器的完结，IA-32完结的时分必定
齐进行判别，然后转换为相应的操作 ，而ARM呢？没有做这个工作，默许以为我们都依照规则就事，你要是竟敢损坏，俺就给你
那有没有办法处理呢？
这个问题其实ARM自己也知道，所以呢，它在编译器里边，现已增加了部分支撑。不过有人会问，那上面那个状况呢？为什么结
有增加什么支撑嘛……
嗯，其实ARM是做了必定的尽力的，仅仅这个状况它没办法处理…… 它做的工作便是：在编译器可以的得知的状况下，尽量确保拜访
话有点抽象，那么把具体状况一个个来看看吧。
编译器的尽力（1）—— 一切部分/大局/静态等变量都放在4字节对齐的地址上
其实这个尽力很常见，因为在32位渠道上，一次拜访4字节是功率最高的，所以大多数32渠道的编译器都如此处理，ARM的ADS也不破例
编译器的尽力（2）—— 填充、填充、再填充
这个工作么，其实也是常见的。各类编译器上，关于某些结构界说中会发生不对齐的状况，主动填充，以进步拜访功率（例如IA
会加1个周期的）。而ARM的编译器也相同操作，不过感觉这儿不单单是为了进步功率，也可以顺带处理这个不对齐的问题。
编译器的尽力（3）—— 发生特别代码
嗯，这个便是要害了，也是ARM编译器的异乎寻常之处。先来看一段代码：
__packed typedef struct _test
{
char a;
short c;
int d;
} test;
char buff[8] = {0x12, 0x34, 0x56, 0x78, 0x9a, 0xab, 0xbc, 0xcd};
test *p = (test *)buff;
v32 = p->d; //这儿的v32借用上面的界说；
形似多了个限定为__packed的struct，以此来形成不对齐的状况，看不出多大差异嘛。但是运转一下的话，就会发现这儿的成果是正
ADS生成的汇编代码吧。
v32 = q->d;
[0xe2890003] add r0,r9,#3
[0xeb000088] bl __rt_uread4
[0xe1a05000] mov r5,r0
看到这儿的那条”bl __rt_uread4″的指令了吧。对ARM指令有必定了解的都知道bl其实便是一个函数调用。所以，这儿的代
自己供给的__rt_uread4函数，该函数完结的操作便是读取四个字节。ADS供给了相似的一系列函数，针对signed/unsigned，以及
写入操作。
估量看到这儿，我们会问，假如没有__packed限定符呢？猜对了，没有__packed限定符，那么编译器会对上面的状况pending，
地点的方位是4字节对齐的（编译期信息，而非实践运转期信息）。所以就回到相似开始的比方了。
那么，还有一种状况，便是在有__packed的状况下，而struct里的字段都是契合对齐要求的，那么生成的代码会是怎么样的呢？
看，和上面的这段汇编代码，仅有的差异便是第一条指令把#3改成了#4，而后边依旧调用__rt_uread4函数。嗯，这样定论就出
编译器会在运用__packed的状况下，主动对其间的4字节/2字节拜访增加特别代码，以确保其成果的正确。
好了，这个关于这个问题描绘得差不多了，或许的话，尽量倚赖编译器的这些功用，而关于编译器力不从心的部分，就要靠万分当心了
p.s. 其实这儿有许多工作可以来尽量防备此类问题，比方嵌入式项目往往喜爱自己办理内存分配，那么自己写的内存分配函数
字节对齐方位上的……
