问题标签 [memory-alignment]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - 内存对齐
我已经理解为什么内存应该根据总线的数据宽度对齐到 4 字节和 8 字节。但是以下陈述使我感到困惑
“IoDrive 要求使用 O_DIRECT 在设备上执行的所有 I/O 必须是 512 字节对齐且大小为 512 字节的倍数。”
将地址对齐到 512 字节需要什么。
c - MIPS memcpy 问题（我认为）
我有一些软件，我在使用 icc 的 redhat 系统上工作，它运行良好。当我将代码移植到使用 MIPS 运行的 IRIX 系统时，我会得到一些计算结果，这些计算结果肯定应该是“nan”。
我在非 redhat 系统上没有任何好的调试器，但我发现我的一些数组偶尔会出现“nan”，这导致我的点积计算返回为“nan”。
看到我无法使用调试器跟踪它，我认为问题可能出在 memcpy 上。带有动态分配数组的 MIPS 编译器 memcpy() 函数是否存在任何问题？我基本上在使用
我无法真正证明这一点，但我认为这可能是问题所在。有一些解决方法吗？也许中小企业数据未对齐？我该如何解决？
c++ - 如何让 tr1::array 分配对齐的内存？
您可以通过定义自己的分配器来分配一个 std::vector 来分配对齐的堆内存。您可以使用 declspec align 在堆栈上分配 c 样式的数组。但是你能声明一个 tr1::array 来保证索引为零的元素对齐吗？
gcc - __attribute__((对齐)) - gcc
gcc将如何设置变量/字段的对齐方式
不同的 gcc 版本/不同的平台呢？
测试代码：
对于 x86、gcc 3.4、4.1、4.3，我得到了 16。
c++ - 为什么在启用 4 字节打包的 C++ 中编译时，由 char、short 和 char（按此顺序）组成的结构会变成 6 字节结构？
我以为我了解 C/C++ 如何处理结构成员对齐。但是对于 Visual Studio 2008 和 2010 中的特定安排，我得到了奇怪的结果。
具体来说，我发现由 char、short 和 char 组成的结构被编译为 6 字节结构，即使启用了 4 或 8 字节打包也是如此。我不知道为什么会这样。我可以理解一个 4 字节的结构。我也许可以理解一个 8 字节的结构。但是我认为当启用 4 字节打包时，6 字节结构是不可能的。
演示该问题的程序是：
输出是：
谁能解释为什么 VC 用一个额外的字节填充每个字符？
c - 为什么 CPU 在字边界上访问内存？
我听说很多数据应该在内存中正确对齐以提高访问效率。CPU 在字边界上访问内存。
所以在下面的场景中，CPU 必须进行 2 次内存访问才能获得一个单词。
为什么会发生这种情况？CPU只能在字边界读取的根本原因是什么？
如果 CPU 只能访问 4 字节的字边界，地址线应该只需要 30 位，而不是 32 位宽度。因为在 CPU 的眼中，最后 2 位始终为 0。
加 1
更重要的是，如果我们承认 CPU 必须在字边界处读取，为什么边界不能从我想要读取的位置开始呢？似乎边界在 CPU 的眼中是固定的。
添加 2
根据AnT的说法，边界设置似乎是硬连线的，它是由内存访问硬件硬连线的。就这一点而言，CPU 是无辜的。
memory-alignment - How to determine if address is word aligned
Can you tell by looking at them which of these addresses is word aligned?
0x000AE430
0X00014432
0X000B0737
0X0E0D8844
malloc - 什么是对齐内存分配？
我也想知道 glibc malloc() 是否这样做。
c++ - 数组大小优化
如果使用 64 位 UNIX 操作系统，将数组大小定义为 8 的倍数是否有任何优势？我打算使用这个数组从共享内存中加载数据。因此依赖关系可能存在于操作系统和页面大小上。
c - 将打包数据与对齐的内存访问相结合
我正在尝试执行理论上应该可行但我开始怀疑是否在 arm-elf-gcc 的能力范围内的内存优化。请告诉我我错了。
我有一个嵌入式系统，它的主内存非常少，电池支持的 nvram 更少。我将校验和配置数据存储在 nvram 中，以便在启动时我可以验证校验和并继续之前的运行或在校验和无效时开始新的运行。在运行期间，我更新了此配置数据中各种大小的字段（这可以使校验和失效，直到稍后重新计算）。
所有这些都在物理地址空间中运行——普通 sram 映射到一个位置，而 nvram 映射到另一个位置。这就是问题所在——所有对 nvram 的访问都必须以 32 位字进行；不允许字节或半字访问（尽管在主存储器中显然没问题）。
所以我可以 a) 将所有配置数据的工作副本存储在主内存中，并在我重新计算校验和时将其 memcpy 到 nvram 或 b) 直接在 nvram 中使用它，但以某种方式说服编译器所有结构都是打包和所有访问不仅必须是 32 位对齐的，而且必须是 32位宽的。
选项 a) 浪费了宝贵的主内存，我更愿意通过选项 b) 进行运行时权衡来保存它（尽管如果代码大小最终浪费的比我节省的数据大小更多）。
我希望它__attribute__ ((packed, aligned(4)))或其中的一些变体可以在这里有所帮助，但是到目前为止我所做的所有阅读和实验都让我失望了。
这是我正在处理的那种配置数据的玩具示例：
您可以想象不同的线程（每个线程执行函数 Foo、Bar 和 Baz）在适当的时候更新它们自己的结构，并在某个时间同步以声明是时候重新计算校验和并进入睡眠状态。