作者：归灵
链接：https://www.zhihu.com/question/23408154/answer/24576669
来源：知乎。
链接：https://www.zhihu.com/question/23408154/answer/24576669
来源：知乎。
------
1.32bCPU和64bCPU的区别？
首先二者的指令集合、操作数位数、寄存器名称和个数等等都不相同；
比如 一条mov eax，1指令，可能在32bCPU上对应的机器指令是0x1201；在64位机器上就是0x123401。程序对于机器CPU而言，仅仅是一系列顺序躺在内存中的01代码而已，而硬件上直接运行的是操作系统，所以你马上得出结论： 32b的CPU只能运行32b的操作系统，64位亦然。
这么设计的确在理论上没什么不妥，实际上intel IA 64架构的处理器就是这样的，64b的CPU上只能运行64b的操作系统（操作系统本身也是软件，也是一系列指令序列）。
但这样问题就来了： 我需要升级硬件来提速，难道买了CPU以后，要把上层的操作系统和应用软件通通换掉？坑碟呢？这种软硬件不兼容带来的问题就是，没有多少客户会去购买这种没法兼容32b原有软件环境的CPU。所以，后来intel和amd都推出了兼容32b原有软件环境的CPU——intel 的x86——64和amd的amd64.
也就是说，现在主流的64b处理器，上面可以运行32b和64b的操作系统。
2.编译器与程序位数？
通常情况下，编译器也仅仅是一个应用软件而已，64b机器上的64b编译器编译出来的也就是64b的应用软件。但是有没有例外呢？
想一想： 第一个64的操作系统是怎么来的？
我们都知道现在操作系统一般是用C语言实现的，然后像普通程序一样经过编译器编译成可执行文件， 难道64b的操作系统不是用64b的编译器编译出来的？
很显然，你的第一个64b的操作系统，需要用“64b”的编译器来生成，但你的64b的编译器运行在什么操作系统上呢？当然，我肯定运行在64b的操作系统之上，那你64b的操作系统从哪里来呢。。。。。。。。。。。。。。是不是觉得陷入循环了！！！！
所以， 必然有一种编译器，本身是32b的软件，但是能够将程序编译成64b的可执行文件，也就是操作系统。也只有这种情况下，编译器本身位数和编译出来程序的位数才不一致。
3.操作系统位数和软件位数的关系
这里，我们首先要弄清一个软件是如何被运行的。
我们以C文件为例，讨论我们经典的hello word程序：
#include<stdio.h>
int main(){
printf("hello world")
}
一个源程序首先被预处理，寻找头文件，将头文件包括进来，里面有printf的申明。
然后被编译成目标文件，注意目标文件已经是二进制文件了，里面的符号表中有main、printf等，但是很显然，这个prinf不是我们自己写的，我们仅仅有它的申明而已。此时如果我们查看目标文件，就会发现目标文件中的printf函数是extern标记，表示这是一个外部符号，并不是我们定义的。
很显然，目标文件是没法运行的，因为里面有未知符号没有解析。
目标文件经过 链接，形成可执行目标文件。因为操作系统提供了已经编译好的动态链接库，所以此时我们仅仅经过链接，神奇的hello就能执行了。
这样， 你是不是没有感觉到你的软件有32b和64b的区别？你管它叫128b都没问题。
但是，上述过过程有几个非常重要的地方：
1）动态链接库
2）系统API
首先，你32b的操作系统上一般是没有64b的库文件的.如果你的应用程序源代码中引用了只有64b的动态库中才有的函数，很显然你链接的时候就会出问题。
量外， 我们很多程序肯定用到了read和write等C语言库函数，而库函数的实现是依赖于系统API的。
如果你工作在windows上，程序大多数是以exe形式发布的，你得到的程序是目标文件以后的结果，本身是带有位数的；如果你工作在linux上，本身大部分软件包rpm等也是已经编译好的，就是说，它们本身就是具有“位数”的。如果你得到的是源码，那么基本上你的应用程序还没有“位数”的概念，你用多少位的编译器去编译它，它就是多少位的应用程序。我们这里讨论多少位的程序，都是针对已经编译到目标文件以后的状态。
4.回到最初的问题：
1）64位的系统上是否能运行32b的应用程序？
2）32b的系统上是否能运行64位的应用程序？
1）对于win系统而言，64b的系统上往往有32b的库和其他必要的信息，基本上能兼容32b的程序。想想，如果不能兼容，那么操作系统肯定比应用软件先出来——毕竟软件是在操作系统上开发的，这样操作系统出来之后，上面32b的软件都不能运行了？
显然不是这样的。也就是说，64b的系统上可以运行32b的程序。
2）32b的系统，一般情况下是没有64b的库的，也没有相关系统api，
一般情况下，32b的系统上没法运行64b的应用程序。
1.32bCPU和64bCPU的区别？
首先二者的指令集合、操作数位数、寄存器名称和个数等等都不相同；
比如 一条mov eax，1指令，可能在32bCPU上对应的机器指令是0x1201；在64位机器上就是0x123401。程序对于机器CPU而言，仅仅是一系列顺序躺在内存中的01代码而已，而硬件上直接运行的是操作系统，所以你马上得出结论： 32b的CPU只能运行32b的操作系统，64位亦然。
这么设计的确在理论上没什么不妥，实际上intel IA 64架构的处理器就是这样的，64b的CPU上只能运行64b的操作系统（操作系统本身也是软件，也是一系列指令序列）。
但这样问题就来了： 我需要升级硬件来提速，难道买了CPU以后，要把上层的操作系统和应用软件通通换掉？坑碟呢？这种软硬件不兼容带来的问题就是，没有多少客户会去购买这种没法兼容32b原有软件环境的CPU。所以，后来intel和amd都推出了兼容32b原有软件环境的CPU——intel 的x86——64和amd的amd64.
也就是说，现在主流的64b处理器，上面可以运行32b和64b的操作系统。
2.编译器与程序位数？
通常情况下，编译器也仅仅是一个应用软件而已，64b机器上的64b编译器编译出来的也就是64b的应用软件。但是有没有例外呢？
想一想： 第一个64的操作系统是怎么来的？
我们都知道现在操作系统一般是用C语言实现的，然后像普通程序一样经过编译器编译成可执行文件， 难道64b的操作系统不是用64b的编译器编译出来的？
很显然，你的第一个64b的操作系统，需要用“64b”的编译器来生成，但你的64b的编译器运行在什么操作系统上呢？当然，我肯定运行在64b的操作系统之上，那你64b的操作系统从哪里来呢。。。。。。。。。。。。。。是不是觉得陷入循环了！！！！
所以， 必然有一种编译器，本身是32b的软件，但是能够将程序编译成64b的可执行文件，也就是操作系统。也只有这种情况下，编译器本身位数和编译出来程序的位数才不一致。
3.操作系统位数和软件位数的关系
这里，我们首先要弄清一个软件是如何被运行的。
我们以C文件为例，讨论我们经典的hello word程序：
#include<stdio.h>
int main(){
printf("hello world")
}
一个源程序首先被预处理，寻找头文件，将头文件包括进来，里面有printf的申明。
然后被编译成目标文件，注意目标文件已经是二进制文件了，里面的符号表中有main、printf等，但是很显然，这个prinf不是我们自己写的，我们仅仅有它的申明而已。此时如果我们查看目标文件，就会发现目标文件中的printf函数是extern标记，表示这是一个外部符号，并不是我们定义的。
很显然，目标文件是没法运行的，因为里面有未知符号没有解析。
目标文件经过 链接，形成可执行目标文件。因为操作系统提供了已经编译好的动态链接库，所以此时我们仅仅经过链接，神奇的hello就能执行了。
这样， 你是不是没有感觉到你的软件有32b和64b的区别？你管它叫128b都没问题。
但是，上述过过程有几个非常重要的地方：
1）动态链接库
2）系统API
首先，你32b的操作系统上一般是没有64b的库文件的.如果你的应用程序源代码中引用了只有64b的动态库中才有的函数，很显然你链接的时候就会出问题。
量外， 我们很多程序肯定用到了read和write等C语言库函数，而库函数的实现是依赖于系统API的。
如果你工作在windows上，程序大多数是以exe形式发布的，你得到的程序是目标文件以后的结果，本身是带有位数的；如果你工作在linux上，本身大部分软件包rpm等也是已经编译好的，就是说，它们本身就是具有“位数”的。如果你得到的是源码，那么基本上你的应用程序还没有“位数”的概念，你用多少位的编译器去编译它，它就是多少位的应用程序。我们这里讨论多少位的程序，都是针对已经编译到目标文件以后的状态。
4.回到最初的问题：
1）64位的系统上是否能运行32b的应用程序？
2）32b的系统上是否能运行64位的应用程序？
1）对于win系统而言，64b的系统上往往有32b的库和其他必要的信息，基本上能兼容32b的程序。想想，如果不能兼容，那么操作系统肯定比应用软件先出来——毕竟软件是在操作系统上开发的，这样操作系统出来之后，上面32b的软件都不能运行了？
显然不是这样的。也就是说，64b的系统上可以运行32b的程序。
2）32b的系统，一般情况下是没有64b的库的，也没有相关系统api，
一般情况下，32b的系统上没法运行64b的应用程序。