关于整数内存分配

时间:2012-10-10 07:04:29

标签: c unix integer 32bit-64bit biginteger

如果分配给整数的内存在任何语言中都有限制(比如说C中的2个字节或4个字节或8个字节)。如何使用32位或64位编译器在32位或64位机器上编译代码。如果这是一个非常微不足道的问题,请原谅我。但请留下答案。

4 个答案:

答案 0 :(得分:3)

如果您使用的是固定大小的整数类型(如int8_tint16_t),那么无论您是针对32位还是64位平台,都无关紧要。

重要的一点是指针的大小。当针对32位架构时,所有指针都是32位,而当针对64位架构时,所有指针都是64位。

过去常常将指针值存储在int中,尽管出于可移植性的原因,这种做法已经变得非常气馁,并且32/64位的情况就是一个很好的例子。如果将指针存储在int中,则在截断指针时,代码将在64位体系结构上调用未定义的行为。当您要提取指针时,您可能会取消引用它可能会崩溃,或者(更糟糕的是)继续使用无效数据。

答案 1 :(得分:1)

为什么必须在32位和64位机器之间编译不同的可执行文件有几个原因 - int的大小可能不是一个因素,或者它可能,因为C标准只定义了最小值和相对大小 - 据我所知,没有int的最大大小(假设它不长于)。

指针的大小是一个主要区别。编译器和链接器在32位和64位进程地址空间之间生成不同的可执行文件布局。运行时库是不同的,动态链接的库(UNIX上的共享对象)必须共享相同大小的指针,否则它们无法与进程的其余部分进行交互。

为什么要使用64位? 64位超过32位的优势是什么?主要优点是指针的最大大小,因此是进程地址空间。 32位是4GB,64位是16EB(大约16,000太字节)。

答案 2 :(得分:0)

如果您查看this page,可以看到C中的基本类型具有一定的保证最小尺寸。因此,您将找不到符合要求的C实现,其中int为2位,必须至少为16位。

平台之间的差异使porting软件成为常见的有趣挑战。

如果您的代码假定有关基本数据类型的事情不能保证是真的(例如,执行类似这样的代码:int x = 0xfeedf00d;),那么该代码将不便携。当在与假设不匹配的平台上编译时,它将以各种通常难以预测的方式破坏。例如,在int为16位的平台上,上面的代码会将x设置为与程序员预期的值不同的值。

答案 3 :(得分:0)

在大多数情况下,字大小会影响性能和堆栈使用。对于给定的体系结构,无论字大小是什么,它都是最快的。如果你定义了两个32位整数,一个接一个,在64位机器上,一个将在一个字边界而另一个不在。将字边界上的那个放入寄存器所需的处理比不在字边界上的处理更少。另一方面,如果在32位机器上定义了64位整数,则需要两次读取才能获得这两个字,并进行一些时髦的寄存器操作以对其执行整数运算。最后一部分与堆栈有关。堆栈总是由单词组成。如果机器的字大小是32位,则堆栈将是32位值的堆栈,而在64位机器上,它们是64位值。并不是说你真的非常在乎,但是32位整数将被放置在堆栈上的64位字中,并且64位值,除非你按指针指向该值,否则将占用堆栈上的两个字。

如果在编译器中选择字对齐,它将自动将所有变量放在字边界上。这要快得多,但占用的空间更多。除非你真的想要空间,否则你应该去表演。并不是说它在CISC架构上有很大的不同。在RISC上它产生了巨大的差异。

这有帮助吗?