int 与 cpu的关系？

liuguilg

为什么说 cpu是16位的， 则int就是16位
         cpu是32位的， 则int就是32位
         cpu是64位的， 则int就是64位

newbraden

64位操作系统int也是4个字节，32位与64位操作系统中一个重大的区别是long型的字节数，前者4字节，后者8字节，其实说到底，所谓32位和64位，是指机器字长的不同

pagx

第三点明显是错的， 至少在windows下不是， linux下也不是, FreeBSD下也不是。这个好像是与某个标准有关。

langue

x86_64 的 CPU，执行 8086 的代码，int 却是 16 位的。这该如何算起呀？

OwnWaterloo

这么说有点牵强吧？

原帖由 langue 于 2009-9-3 23:42 发表
执行 8086 的代码，int 却是 16 位的

int为16的代码， 是编译器"为"（以xxx为target）8086生成的。

如果这个算反例， 那所有模拟器都是反例了。


将讨论限定在"int 与 '目标'cpu的关系"， 是否更有意义一点？

langue

原帖由 OwnWaterloo 于 2009-9-3 23:57 发表
这么说有点牵强吧？

是比较牵强。

将讨论限定在"int 与 '目标'cpu的关系"， 是否更有意义一点？

我觉得可以说两点。
一是标准只规定了各种类型的最小范围，各个厂商提供 <limit.h> 和 <float.h>，里面是实现的各种 capabilities & limits。
二，各个 target 的情况不一样，每个 target 都有约定俗成的 <limit.h>，而且必须意识到，同一种 CPU 可以运行为多种 target 生成的代码，比如 AMD64 的 CPU 可以兼容 16 位和 32 位代码。

第一条是事实，不需要再讨论。
倒是可以就第二条说一说。

对于这个“约定俗成”，我认为，通常是这样考虑的，至少有两点：
1、考虑到编译器的实现方便，尽量用 CPU 的通用寄存器大小作为 int size；
2、考虑到移植程序的复杂度，尽量不要做一个和其它 target 差别太大的怪物出来。

请指正、补充，谢谢。

OwnWaterloo

原帖由 langue 于 2009-9-4 01:31 发表
1、考虑到编译器的实现方便，尽量用 CPU 的通用寄存器大小作为 int size；

其实在这点上， 我一直没想明白 ……

OwnWaterloo

我是说，  64位机上， int 应该如何是好 ……

iamlyg98

int占用的位宽应该是由编译器实现的，但是int的宽度与CPU的内部寄存器的宽度一致是有好处的，
比如一个CPU的内部寄存器的宽度是32位的，该CPU的内部数据总线也是32位的，则该ＣＰＵ
一次读／写操作的最佳宽度就是３２位。如果在３２位的ＣＰＵ上读／写１６位的数据，则ＣＰＵ
通常会读３２位的数据，然后把高１６位清零。不过需要注意的是有些３２位的ＣＰＵ是提供１６位
８位的寄存器共用户访问，但有些３２位的ＣＰＵ就没有提供１６位的寄存器。