Chinaunix

标题: 64位的操作系统编程一样吗 [打印本页]

作者: wangxinus 时间: 2009-10-09 20:34
标题: 64位的操作系统编程一样吗
rt!
编译器分不分 32 64位？标准库呢？对齐方式会不会改？编译出来的就是64位的程序了吗？32位系统能运行吗？

作者: lewphee 时间: 2009-10-09 23:04
标题: 回复 #1 wangxinus 的帖子
肯定不是一样的啦~！！晕，不然别人白写64位编程指南啦~！！

作者: nizvoo 时间: 2009-10-09 23:30
64位编译的不能再32位上用，32位的可以在64位用

作者: c/unix 时间: 2009-10-09 23:39
提示: 作者被禁止或删除内容自动屏蔽

作者: langue 时间: 2009-10-09 23:44
标题: 回复 #4 c/unix 的帖子
也许他说的是32位兼容模式，此时CPU工作在32位。

作者: 梦幻无情 时间: 2009-10-10 08:23

原帖由 nizvoo 于 2009-10-9 23:30 发表
64位编译的不能再32位上用，32位的可以在64位用

验证过没？

作者: VIP_fuck 时间: 2009-10-10 09:11
64和32还是有一些区别的。
最好还是别把32的程序拿到64上运行，也别反着来。
有时候因为数据长度不一样，会产生很奇怪的结果。这种bug也很不好修改。

作者: net_robber 时间: 2009-10-10 09:32
有的64位Linux发行版，同事带有32位和64位的库，以处理64位系统运行32位程序问题

作者: net_robber 时间: 2009-10-10 09:32
如果64位系统只有64位的库，那还是不要运行32位程序的好

作者: yulihua49 时间: 2009-10-10 15:51

原帖由 wangxinus 于 2009-10-9 20:34 发表
rt!
编译器分不分 32 64位？标准库呢？对齐方式会不会改？编译出来的就是64位的程序了吗？32位系统能运行吗？

不太一样。
long是64位的，地址也是64位，结构中某些边界按8字节对齐，用sizeof（）可以测出来。
我们测量两种模式，还是64位快，2-2.5倍。

[ 本帖最后由 yulihua49 于 2009-10-10 15:52 编辑 ]

作者: 齐得龙强更强 时间: 2009-10-10 15:57

原帖由 c/unix 于 2009-10-9 23:39 发表

32位的可以在64位用，你确定？

我试过可以运行，但是

作者: 齐得龙强更强 时间: 2009-10-10 15:59

原帖由 VIP_fuck 于 2009-10-10 09:11 发表
64和32还是有一些区别的。
最好还是别把32的程序拿到64上运行，也别反着来。
有时候因为数据长度不一样，会产生很奇怪的结果。这种bug也很不好修改。

64 上编译的程序不能在32上运行， 32 编译的程序能在64上运行，我刚试过！

作者: wangxinus 时间: 2009-10-10 23:29

原帖由 yulihua49 于 2009-10-10 15:51 发表

不太一样。
long是64位的，地址也是64位，结构中某些边界按8字节对齐，用sizeof（）可以测出来。
我们测量两种模式，还是64位快，2-2.5倍。

以前用的系统多是32位的，但是这次我准备尝试一下64位的操作系统。
想问一下各位，平时编程用的32位系统还是64位的？

我准备用fedora，据说64位的兼容性比较好，各位觉得呢？

作者: zpp71 时间: 2009-10-12 14:46
1 指针拥有8个字节，不再是那个和intl类型长短一样了。它将带来的好处就是，系统具有更为广阔的寻址空间。寻址范围从4GB变成了4EB。

2 虚拟内存不再是2GB(3GB)，为什么不是4GB，因为另外的那2GB是内核用来做映射需要占用的。具体原因参看其他的文章。那么虚拟内存到底编程多大了？4EB/2 2EB。实际不是这样的，它被限定为4TB不过这个大小已经可以让我们爽几年。

3 分页变化，可分页和不可分页内存池大小由470MB，256MB变为了128GB。暂时不会再出现分页不足的问题。每个页表从4k变为了8k。这点是需要小心的，每个页表的大小应该是没有变化。应该是由1024 x 4 bytes变为了1024x8bytes。

4 变量大小，在64位系统中long类型有可能不在委屈的使用4自己，而拥有了8字节。这里只能说是可能，因为根据编译器的不同具体的每种类型占多少空间还不能确定。在64位编译器中会出现4中不同的数据模型

Data model short int long long long pointers
LLP64 16 32 32 64 64
LP64 16 32 64 64 64
ILP64 16 64 64 64 64
SILP64 64 64 64 64 64

大部分的编译器将会使用LP64。而微软的编译器貌似会继续使用LLP64。也就是说从VC++系列一直代码将更加容易。
5CTime对象，这个对象在32位系统中不是让很非常满意，因为它使用long类型记录时间，导致时间范围只能是
0-4 2 9 4 9 6 7 2 9 5
1970年1月1日-2 0 3 7年

6 内存对齐

Itanium架构的系统将把内存对齐的问题推给开发人员。开发人员的错误使用会使得性能变慢，乃至系统崩溃。

7 性能提高

8 系统内核操作，可能现在的HOOK操作不能够在64位系统中正确的运行。

9 汇编，这个变化可能是最大的，所有的偏移量计算可能都需要重新计算。

参考：http://blog.csdn.net/Splendour/archive/2009/01/07/3726564.aspx

作者: VIP_fuck 时间: 2009-10-12 15:15
标题: 回复 #12 齐得龙强更强的帖子
呵呵，这个怎么说那。
我只能说说我的经验吧。

我说的比较直接啊，别生气啊。

程序运行成功，没有问题，是程序的结构比较简单。当涉及东西多了，问题自然就出现了。

作者: koolcoy 时间: 2009-10-12 16:50
标题: 回复 #14 zpp71 的帖子
此文有错误，参考请慎重

作者: yylogo 时间: 2009-10-12 19:17
标题: 回复 #4 c/unix 的帖子
一般可以, 一般硬件向以前兼容

作者: prolj 时间: 2009-10-12 19:20
multilib google一下。

作者: zpp71 时间: 2009-10-12 21:53

原帖由 koolcoy 于 2009-10-12 16:50 发表
此文有错误，参考请慎重

请赐教？

作者: koolcoy 时间: 2009-10-13 10:36

原帖由 zpp71 于 2009-10-12 21:53 发表

请赐教？

就x64而言：
>>每个页表从4k变为了8k
x64支持好几种页表
那个可分页和不可分页内存我没看懂是什么意思~~

[ 本帖最后由 koolcoy 于 2009-10-13 10:37 编辑 ]

作者: gz80 时间: 2009-10-13 11:57
如果64位系统能运行32位的程序的话，那么是怎么识别程序的字长呢？elf头里面有指示？

作者: gawk 时间: 2009-10-13 13:32
坐等64位

作者: redor 时间: 2009-10-13 13:55

原帖由 c/unix 于 2009-10-9 23:39 发表

32位的可以在64位用，你确定？

他说的应该是可以编译成32位模式在64位系统上运行, gcc的 -m32 -m64就用来干这活的

作者: 齐得龙强更强 时间: 2009-10-13 17:38

原帖由 redor 于 2009-10-13 13:55 发表

他说的应该是可以编译成32位模式在64位系统上运行, gcc的 -m32 -m64就用来干这活的

我这里有一个32上编译的库文件，在64上用的时候，老是编译不过去，不知道用gcc的 -m32 能不能在64上编译过去！！

作者: chinesedragon 时间: 2009-10-13 21:29
应该不一样

作者: unistd001 时间: 2009-10-13 21:53
差不多，要是你从新创建一个项目的话。。
区别就是64位字长比32位的长了罢了，，要是说有区别的话，那也是原来的项目或者开发工具本身设计的不好。。。
我觉得gun系列开发工具应该和.net学习一下，，里面定义很多绝对的类型，比如int8 , int16 ,int32等等，然后根据平台把int映射到int32或者int64 ，吧所有与硬件有关的定义都设置成可变的，那就没问题。

作者: lanck 时间: 2009-10-13 22:45

原帖由 nizvoo 于 2009-10-9 23:30 发表
64位编译的不能再32位上用，32位的可以在64位用

VS2008 无论在64位还32位环境下都能编译出可在64位或32位下运行的程序

作者: creatory 时间: 2009-10-14 07:08
64位机子最大访内空间2^64,可受到64位操作系统的管理，而32位的最大访问空间为2^32，程序利用的空间就少，地址映射就不如64位的。

作者: hsqsoft 时间: 2009-10-14 07:12
标题: 回复 #1 wangxinus 的帖子
肯定不是一样的

作者: btmingxin 时间: 2009-10-14 15:53
压瓦机（明信）

作者: Magicloud 时间: 2009-10-16 14:47

原帖由 wangxinus 于 2009-10-9 20:34 发表
rt!
编译器分不分 32 64位？标准库呢？对齐方式会不会改？编译出来的就是64位的程序了吗？32位系统能运行吗？

你说编译器，是指编译器这个程序，还是编译这个功能呢？如果是程序，当然有32／64之分。如果是功能，那至少g++支持跨平台编译。
标准库的代码有少量32／64之分，.o是完全分别的。
对齐是否有区别看机器架构。
64程序一般不能在32机器上运行。
32程序是否能在64机器上运行取决于硬件支持，没有必然。

作者: blackuhlan 时间: 2009-10-20 16:59
硬件如果不支持就在前32位全补0，可不可以呢？

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)