问题标签 [memory-alignment]

我一直是高级编码员，架构对我来说很新，所以我决定在这里阅读关于组装的教程：

http://en.wikibooks.org/wiki/X86_Assembly/Print_Version

在教程的最后，关于如何转换 Hello World 的说明！程序

给出了等效的汇编代码，并生成了以下内容：

对于其中一条线，

解释是：

此代码“和”s ESP 与 0xFFFFFFF0，将堆栈与下一个最低 16 字节边界对齐。对 Mingw 源代码的检查表明，这可能是针对出现在“_main”例程中的 SIMD 指令，它只对对齐的地址进行操作。由于我们的例程不包含 SIMD 指令，因此这一行是不必要的。

我不明白这一点。有人可以解释一下将堆栈与下一个 16 字节边界对齐的含义以及为什么需要它吗？以及如何andl实现这一目标？

有人能告诉我对齐指针的实际含义吗？

这段代码似乎有效，但我是否正确使用了 InterlockedIncrement 函数？m_count 的正确内存对齐是我最关心的问题。假设我们在 x86-64 系统上并编译一个 64 位应用程序（以防万一）。顺便说一句，出于我的实际目的，我不能将 m_count 声明为 volatile long 然后使用 InterlockedIncrement(&m_count); 但它必须是指向堆中数据的指针。

如果我们在堆栈中创建这种类型的对象，是否可以保证该对象的内存将正确对齐？

如果我们在堆栈中创建 char bytes[4] 然后尝试将其转换为整数，则可能存在对齐问题。我们可以通过在堆中创建它来避免这个问题，但是，联合对象有这样的保证吗？逻辑上应该有，但我想确认一下。

谢谢。

为什么我们需要在 C++#pragma pack中使用结构？typedef特别是当您在网络通信中使用这些结构时。

http://www.alex-ionescu.com/?p=50。

我读了上面的帖子。作者通过单链表示例解释了为什么 Windows x64 只支持 44 位虚拟内存地址。

首先要做的牺牲是将序列号的空间减少到 9 位而不是 16 位，从而减少列表可以实现的最大序列号。这仍然只为指针留下了 39 位——对 32 位的改进是平庸的。通过在分配时强制结构为 16 字节对齐，可以再赢得 4 位，因为现在可以始终假定底部位为 0。

哦，我无法理解。

什么“通过在分配时强制结构为 16 字节对齐，可以再赢得 4 位，因为现在可以始终假定底部位为 0。” 方法？

我有结构

a是整数变量，所以它需要 4 个字节，c是 char 变量，所以它需要 1 个字节，总共 5 个字节

但是当我打印sizeof(obj)它显示8 bytes。

是什么原因？

我想知道，大多数实现是否也calloc将大小视为对齐，并将其四舍五入到下一个支持的粒度？

如果是这样，那么它们是四舍五入到 2 的下一个幂，还是四舍五入到 8 或 16 的下一个倍数？

如果calloc保持参数相同，那么它是如何工作的呢？你的数据不会不对齐吗？

谢谢！

我正在为二进制协议（Javad GRIL 协议）编写解码器。它由大约一百条消息组成，数据格式如下：

这些字段是 ANSI 编码的二进制数，它们彼此没有间隙。解析此类消息的最简单方法是将输入的字节数组转换为适当的类型。问题是流中的数据是打包的，即未对齐的。

在 x86 上，这可以通过使用#pragma pack(1). 但是，这在其他一些平台上不起作用，或者由于进一步处理未对齐的数据而导致性能开销。

另一种方法是为每种消息类型编写一个特定的解析函数，但正如我所提到的，该协议包含数百条消息。

另一种选择是使用类似 Perl 的unpack()函数并将消息格式存储在某处。说，我们可以#define MsgDataFormat "CfffC"然后打电话unpack(pMsgBody, MsgDataFormat)。这要短得多，但仍然容易出错和冗余。此外，格式可能更复杂，因为消息可以包含数组，因此解析器会很慢而且很复杂。

有没有普遍有效的解决办法？我已经阅读了这篇文章并在 Google 上四处搜索，但没有找到更好的方法。

也许 C++ 有解决方案？

有

my_ptr 会指向 ptr 之后的 1 个字节，还是指向 ptrsizeof(any_type)之后的字节？对齐选项如何影响答案？有符号/无符号类型有什么不同吗？