malloc（）/free（）的对齐限制-解网

问：

我读过的旧 K&R（第 2 版）和其他 C 语言文本，它们以显然，某些计算机硬件体系结构（CPU、寄存器和内存访问）限制了存储和寻址某些值类型的方式。例如，可能要求 4 字节（）整数必须从地址的倍数开始存储，地址是 4 的倍数。malloc()free()long

主要平台（Intel & AMD、SPARC、Alpha）对内存分配和内存访问施加了哪些限制（如果有），或者我可以安全地忽略在特定地址边界上对齐内存分配？

C 内存 malloc 分配

今天，对齐仍然非常重要。某些处理器（我想到了 68k 系列）如果您尝试访问奇数边界上的字值，则会引发异常。今天，大多数处理器将运行两个内存周期来获取未对齐的单词，但这肯定会比对齐的读取慢。其他一些处理器甚至不会抛出异常，但会从内存中获取不正确的值！

如果除了性能之外没有其他原因，那么尝试遵循处理器的对齐首选项是明智的。通常，你的编译器会处理所有细节，但如果你正在做任何事情，你要自己布置内存结构，那么就值得考虑了。

1赞 Rob Walker 8/31/2008 #2

在 C（++）中布局类或结构时，您仍然需要注意对齐问题。在这些情况下，编译器会为你做正确的事情，但结构/类的整体大小可能比必要的更浪费

例如：

struct
{ 
    char A;
    int B;
    char C;
    int D;
};

大小为 4 * 4 = 16 字节（假设 x86 上的 Windows），而

struct
{ 
    char A;
    char C;
    int B;
    int D;
};

大小为 4*3 = 12 字节。

这是因为编译器对整数强制执行 4 字节对齐，但对字符只强制执行 1 字节对齐。

通常，将相同大小（类型）的成员变量打包在一起，以最大程度地减少空间浪费。

1赞 denis phillips 8/31/2008 #3

正如 Greg 所提到的，它在今天仍然很重要（也许在某些方面更重要），编译器通常会根据架构的目标来处理对齐。在托管环境中，JIT 编译器可以根据运行时体系结构优化对齐方式。

您可能会看到更改对齐方式的编译指示（在 C/C++ 中）。仅当需要非常具体的对齐时，才应使用此选项。

// For example, this changes the pack to 2 byte alignment.
#pragma pack(2)

6赞 DGentry 9/6/2008 #4

Sparc、MIPS、Alpha 和大多数其他“经典 RISC”架构只允许对内存进行对齐访问，即使在今天也是如此。未对齐的访问将导致异常，但某些操作系统将通过使用较小的负载和存储从软件中的所需地址复制来处理异常。应用程序代码不会知道有问题，只是性能会很差。

MIPS 具有特殊指令（lwl 和 lwr），可用于从未对齐地址访问 32 位数量。每当编译器可以判断地址可能未对齐时，它就会使用这两个指令序列，而不是普通的 lw 指令。

x86 可以毫无例外地处理硬件中未对齐的内存访问，但与对齐访问相比，性能仍会下降 3 倍。

乌尔里希·德雷珀（Ulrich Drepper）写了一篇关于这个和其他与内存相关的主题的综合论文，每个程序员都应该知道的关于内存的知识。这是一篇很长的文章，但充满了耐嚼的优点。

1赞 Pramod 9/6/2008 #5

请注意，即使在 IA-32 和 AMD64 上，某些 SSE 指令/内部函数也需要对齐的数据。如果数据未对齐，这些指令将引发异常，因此至少您不必调试“错误数据”错误。也有等效的未对齐指令，但就像丹顿说的，速度较慢。

如果您使用的是 VC++，那么除了 #pragma pack 指令之外，您还有用于精确对齐的 __declspec（align）指令。VC++ 文档还提到了用于特定对齐要求的 __aligned_malloc 函数。

根据经验，除非您跨编译器/语言移动数据或使用 SSE 指令，否则您可能会忽略对齐问题。

malloc（）/free（）的对齐限制