代码之家 › 专栏 › 技术社区 › Burcu Dogan

整数和寄存器大小之间有关系吗?

cpu-registers cpu integer memory c++

Burcu Dogan · 技术社区 · 16 年前

没有真正考虑数组长度,我犯了一个奇怪的错误,没有使用size\u t而是使用int进行迭代。我知道它不兼容,也不安全。

int i, size = _tcslen(str);    
for(i=0; i<size; i++){
   // code here
}

但是,我们可以分配的最大内存是有限的。如果int和寄存器大小之间存在关系,则可以安全地使用整数。

例如:没有任何虚拟映射工具,我们只能映射2^个寄存器大小的字节。由于TCHAR的长度为2字节,因此为该数字的一半。对于任何将int设置为32位的系统,即使您不使用int的无符号版本,这也不会是一个问题。具有嵌入式背景的人通常认为int为16位,但这种设备上的内存大小将受到限制。所以我想知道在整数和寄存器大小之间是否有一个体系结构微调决定。

6 回复 | 直到 16 年前

Stack Overflow is garbage 16 年前

C++标准没有指定int的大小(它表示)。 sizeof(char) == 1 和 sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) .

与寄存器大小有关。一个完全一致的C++实现可以在您的PC上提供32位寄存器,并带有32位寄存器。但这样做效率很低。

所以,是的,在实践中 int 数据类型通常等于CPU的通用寄存器的大小,因为这是迄今为止最有效的选择。

如果比寄存器大,那么简单的算术运算将需要不止一条指令,这将是昂贵的。如果它们比寄存器小,那么加载和存储寄存器的值需要程序屏蔽未使用的位,以避免覆盖其他数据。(这就是为什么 int 数据类型通常比 short .)

(有些语言只需要 int 为32位,在这种情况下,显然与寄存器大小没有关系,只是选择了32位,因为它是一个公共寄存器大小)

Tal Pressman 16 年前

严格按照标准,无法保证int的大小,更不用说与寄存器大小的关系了。此外,一些体系结构具有不同大小的寄存器(即:并非CPU上的所有寄存器都具有相同的大小),并且并非总是使用一个寄存器访问内存(如DOS及其段:偏移寻址)。尽管如此,在大多数情况下int与“常规”寄存器的大小相同,因为它应该是最常用的基本类型,而这正是CPU优化操作的对象。

CÄtÄlin PitiÈ 16 年前

另外,寄存器大小和int的大小之间没有直接联系。

实例

#ifdef WIN32 // Types for Win32 target
#define Int16 short
#define Int32 int
// .. etc.
#elif defined // for another target

Juergen 16 年前

如果我理解正确的话,我并不完全清楚,因为这里混合了一些不同的问题(内存大小、分配、寄存器大小、性能?)。

我可以说的是(以标题为例),在大多数实际处理器上,为了获得最大速度,应该使用与寄存器大小匹配的整数。原因是,当使用较小的整数时,需要的内存较少, 例如,在x86体系结构上,需要一个额外的转换命令。同样在Intel上,您也有一个问题,即访问未对齐(主要在寄存器大小的边界上)内存会带来一些惩罚。当然,在今天的处理器上,事情更加复杂,因为CPU能够并行处理命令。因此,您最终需要对某些体系结构进行微调。

因此,最好的猜测——不知道体系结构——是使用寄存器大小的整数,只要你能负担得起内存。

Max Lybbert 16 年前

我没有标准的副本,但是我的旧版本 C语言 int 指“一个整数,通常反映主机上整数的自然大小。” C++程序设计语言 说明(第4.6节)“ 应该选择最适合在给定计算机上保存和操作整数的类型。”

你不是唯一一个说“我承认这一点”的人 this is technically a flaw, but it's not really exploitable ."

Mr Fooz 16 年前

有各种不同大小的寄存器。重要的是地址寄存器,而不是通用寄存器。如果机器是64位的,那么地址寄存器(或它们的一些组合)必须是64位的,即使通用寄存器是32位的。在这种情况下,编译器可能需要做一些额外的工作来使用多个通用寄存器实际计算64位地址。

如果你不认为硬件制造商曾经为他们的寄存器做出过奇怪的设计选择,那么你可能永远都不需要处理原始的8086“ real mode “寻址。