AArch64是否支持不对齐访问? [英] Does AArch64 support unaligned access?

查看:186
本文介绍了AArch64是否支持不对齐访问?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

AArch64是否原生支持不对齐访问?我问是因为当前 ocamlopt 假定为否。

Does AArch64 support unaligned access natively? I am asking because currently ocamlopt assumes "no".

推荐答案

提供严格对齐检查的硬件位未打开(与在x86上一样,实际上没有通用OS可用),AArch64允许使用常规加载/存储指令对常规(非设备)内存进行未对齐的数据访问

Providing the hardware bit for strict alignment checking is not turned on (which, as on x86, no general-purpose OS is realistically going to do), AArch64 does permit unaligned data accesses to Normal (not Device) memory with the regular load/store instructions.

但是,编译器仍然希望保持对齐的数据有几个原因:

However, there are several reasons why a compiler would still want to maintain aligned data:


  • 读写原子:保证自然对齐的加载和存储是原子的,即,如果一个线程同时读取对齐的内存位置,而另一个线程写入相同的位置,则该读取将仅返回旧值或新值。如果位置未与访问大小对齐,则该保证不适用-在这种情况下,读取可能返回这两个值的未知混合。如果该语言具有并发模型,则该模型不会发生这种情况。

  • 原子读取-修改-写入操作:如果该语言具有并发模型,可以原子地更新(而不仅仅是读取或写入)某些或所有数据类型,然后对于这些操作,代码生成将涉及使用独占负载/独占存储指令来建立原子读取-修改-写入序列,而不是简单的加载/存储。如果地址未与访问大小对齐,则排他性指令始终会出错。

  • 效率:在大多数内核上,未对齐的访问最多仍比正常的访问至少花费1个周期以上。对齐一个。在最坏的情况下,单个未对齐的访问会越过缓存行边界(本身具有额外的开销),并生成两个缓存未命中甚至两个连续的页面错误。除非您处于内存不足的环境中,或者无法控制数据布局(例如,将数据包从网络接收缓冲区中拉出),否则仍然最好避免未对齐的数据。

  • 必要性:如果该语言具有合适的数据模型,即没有指针,并且来自外部源的任何数据都已被整理为较低级别的合适数据类型,那么无论如何实际上都不需要未对齐的访问,这使编译器的寿命变得如此长更容易简单地完全忽略该想法。

  • Atomicity of reads and writes: naturally-aligned loads and stores are guaranteed to be atomic, i.e. if one thread reads an aligned memory location simultaneously with another thread writing the same location, the read will only ever return the old value or the new value. That guarantee does not apply if the location is not aligned to the access size - in that case the read could return some unknown mixture of the two values. If the language has a concurrency model which relies on that not happening, it's probably not going to allow unaligned data.
  • Atomic read-modify-write operations: If the language has a concurrency model in which some or all data types can be updated (not just read or written) atomically, then for those operations the code generation will involve using the load-exclusive/store-exclusive instructions to build up atomic read-modify-write sequences, rather than plain loads/stores. The exclusive instructions will always fault if the address is not aligned to the access size.
  • Efficiency: On most cores, an unaligned access at best still takes at least 1 cycle longer than a properly-aligned one. In the worst case, a single unaligned access can cross a cache line boundary (which has additional overhead in itself), and generate two cache misses or even two consecutive page faults. Unless you're in an incredibly memory-constrained environment, or have no control over the data layout (e.g. pulling packets out of a network receive buffer), unaligned data is still best avoided.
  • Necessity: If the language has a suitable data model, i.e. no pointers, and any data from external sources is already marshalled into appropriate datatypes at a lower level, then there's really no need for unaligned accesses anyway, and it makes the compiler's life that much easier to simply ignore the idea altogether.

我不知道特别关注OCaml的是什么,但是如果我对OCaml感兴趣,我当然不会感到惊讶就是以上所有。

I have no idea what concerns OCaml in particular, but I certainly wouldn't be surprised if it were "all of the above".

这篇关于AArch64是否支持不对齐访问?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆