iOS设备上是否允许未对齐的内存访问？

我目前正在开发一个应用程序，该应用程序加载一团紧密压缩的数据，其中包含可能未正确对齐的不同整数类型（大小从char到int）

那么，我可以使用简单的

*（short*）ptr

或类似的方法访问该数据吗？在我的iPhone5上进行的测试表明这没有问题，但我不确定所有新处理器上的所有情况

我确实找到了一些相关信息，比如：

除某些微控制器版本外，ARMv6及更高版本支持半字和单字加载/存储指令的未对齐访问，但存在一些限制，例如没有保证原子性

但对于单词，似乎在32位和64位上，单词32和64位对应，这意味着short需要在64位机器上正确对齐

那么，我可以假设这是安全的，还是应该使用一些关键字，比如

\uu packed

？

---

或者我应该完全避免它，重新创建我的数据，使其始终具有正确的对齐方式（或者当数据来自外部源且无法永久修改时，始终使用memmove）？

我早就尝试过了。它确实起作用了，但是每次对未对齐内存的访问都会导致一个陷阱，这需要相当长的时间。我建议你衡量一下添加一百万条对齐短裤和一百万条未对齐短裤所需的时间。如果您有几百或几千个未对齐的数字，则无需担心

---

__包装工作相当快。ARM有一些聪明的指令，可以用很少的指令进行未对齐的访问。再一次，我会测量这需要多长时间。我在这方面的经验不是最新的

嗯，我担心的主要问题是，在某些处理器上，其中一个操作将不受支持，但也许我过于谨慎了。在我的设备上没有崩溃（在我计划使用的版本设置上）。至于速度，32位和64位的东西更喜欢4字节对齐，而16位的偏移量更差（总是不均匀的，可能是一些不吉利的缓存情况）。慢速版本的运行速度总是比快速版本慢约2倍。从ARMv6文档（ARMv6+的现代ARM），OP POST可以进行未对齐的访问（如果配置了CP15）而不是陷阱。不能“原子地”写入未对齐的访问。它可能需要多个总线周期，CPU可能会中断；一半可能在缓存中，等等。对于iOS，我猜他们总是允许未对齐的访问，因为我认为他们没有ARMv5或更低版本的设备？这可能是“允许的”，但可能不会很快。最好先读取字节，然后用位移位或测试来构造对齐的数据类型，以确保编译器生成了正确的代码。