（u）intN_t总是与N位对齐？

Question

1. 例如，在体系结构x86上，64位整数可以安全地对齐到32位而不会受到惩罚，因为仍然需要进行部分计算：整数根本不适合寄存器。对于__（u）int128，一切都是一样的。但通常它们与存储时的位数相同。这对所有现代和未来可能的架构都是如此吗？

2. 同一个int8_t或int16_t可以在某处与32位对齐吗？

谈到未来，我的意思不是革命性的建筑，甚至在出生之前就已经死了。字节事实上包含8位，二进制补码，平面寻址，页面等。开发向量已经设置，不会有偏差。但是对齐问题很有意思。

Answer 1

64位整数在x86上是4字节对齐的，但如果你采用其他32位架构，如ARM，MIPS和PowerPC，那么你可以看到64位整数需要在8字节边界对齐。 / p>

这不是特定于处理器的，因为64位加载和存储是使用两个4字节访问在软件中模拟的。相反，这是C编译器使用的ABI的一部分。我只能猜测为什么他们选择这样做，很可能是由于性能：无论CPU寄存器的大小如何，CPU总线今天可能比32位宽，所以加载/存储8字节整数如果它们更快8字节对齐。另一个原因是，对于原子操作，8字节整数仍然必须在8字节边界处对齐。

所以是的，(u)intN_t始终与x86_64，ARM，AArch64，PowerPC，PowerPC64，MIPS，MIPS64上的N位对齐。由你来决定这是否足够现代和＃34;。但是在未来，无论处理器GPR的宽度如何，由于性能的原因，8字节整数可能会使用8字节对齐。

非标准128位和更大整数的情况可能会有所不同。由于数据通常从缓存行中的缓存中提取（通常为64字节），因此将它们进行128位对齐也更有效，但实现可能不会出于任何原因选择这样做。但是128位整数是非标准的，你可能仍然需要为那些提供平台相关的解决方案，所以你可以修复＆＃34;他们也是一致的。目前，GCC在AArch64，x86_64，PowerPC64上保持__int128 16字节对齐。

至于未来的架构，我会说他们必须提供类似的环境，否则他们会遇到很多软件的问题。大多数软件的可移植性都被夸大了。这种不常见的架构有可能在今天变得流行吗？不太可能。你需要支持吗？可能不是，它可能是如此特殊，你的软件无论如何都不会在它上面工作。