2个回答
展开全部
不能，64位程序（系统）需要64位cpu支持，而32位cpu不支持64位程序！
以下为引用：
64 位系统有时缺乏对应的软件，那些软件是写给 32 位架构。最严重的问题是不兼容的驱动程序。尽管大部分软件可执行于 32 位兼容模式（又称作模拟模式，即微软 WoW64 技术），其通常无法执行驱动程序（或类似软件），因为程序通常执行于操作系统和硬件之间，在此直接模拟无法使用。许多开放源始码软件封包可简单的从源始码编译为可执行于 64 位环境操作系统，如 Linux。所需的条件是供给 64 位机器的编译器（通常是 gcc）。目前大部分 64 位版本的驱动程序还不能用，由于缺少可用的驱动程序，所以使用 64 位操作系统会有挫折。
因为设备的驱动程序通常执行于操作系统内核（kernel）的内部，有可能以 32 位进程执行内核，同时支持 64 位的使用者进程。以在内核里的额外消耗为代价，如此可为使用者提供受益于 64 位的内存和效能，且不破坏现存 32 位驱动程序的二进制兼容性。这个机制源于 Mac OS X 启用 64 位进程，同时支持 32 位的驱动程序。
从 32位到 64 位架构的改变是一个根本的改变，因为大多数操作系统必须进行全面性修改，以取得新架构的优点。其它软件也必须进行移植，以使用新的性能；较旧的软件一般可借由硬件兼容模式（新的处理器支持较旧的 32 位版本指令集）或软件模拟进行支持。或者直接在 64 位处理器里面实作 32 位处理器内核（如同 Intel 的 Itanium 处理器，其内含有 x86 处理器内核，用来执行 32 位 x86 应用程序）。支持 64 位架构的操作系统，一般同时支持 32 位和 64 位的应用程序。
明显的例外是 AS/400，其软件执行在虚拟的指令集架构，称为 TIMI（技术独立机器界面），它会在执行之前，以低阶软件转换成本地机器码。低阶软件必须全部重写，以搬移整个 OS 以及所有的软件到新的平台。例如，当 IBM 转移较旧的 32/48 位“IMPI”指令集到 64 位 PowerPC（IMPI 完全不像 32 位 PowerPC，所以这比从 32 位版本的指令集转移到相同指令集的 64 位版本的规模还要庞大）。
64 位架构无疑可应用在需要处理大量数据的应用程序，如数码视频、科学运算、和早期的大型数据库。在其它工作方面，其 32 位兼容模式是否会快过同等级的 32 位系统，这部分已有很多争论。在 x86-64 架构（AMD64 和 Intel 64）中，主要的 32 位操作系统和应用程序，可平滑的执行于 64 位硬件上。
Sun 的 64 位 Java虚拟机的启动速度比 32 位虚拟机还慢，因为 Sun 仍假定所有的 64 位机器都是服务器，而且只有为 64 位平台实作“服务器”编译器（C2）。“客户端”编译器（C1）产生较慢的代码，不过编译较快速。所以尽管在 64 位 JVM 的 Java 程序在一段很长的周期会执行的较好（一般为长时间运作的“服务器”应用程序），它的启动时间可能更久。对于短生命期的应用程序（如 Java 编译器 javac） 增加启动时间可控制执行时间，使 64 位的 JVM 整体变慢。
应当指出，在比较 32 位和 64 位处理器时，速度并不是唯一的考量因素。应用程序，如多任务、应力测试（stress testing）、丛集（clustering）（用于HPC）可能更适合 64 位架构以正确部署。为了以上原因，64 位丛集已广泛部署于大型组织，如 IBM、Vodafone、HP、微软。
是否可以解决您的问题？
以下为引用：
64 位系统有时缺乏对应的软件，那些软件是写给 32 位架构。最严重的问题是不兼容的驱动程序。尽管大部分软件可执行于 32 位兼容模式（又称作模拟模式，即微软 WoW64 技术），其通常无法执行驱动程序（或类似软件），因为程序通常执行于操作系统和硬件之间，在此直接模拟无法使用。许多开放源始码软件封包可简单的从源始码编译为可执行于 64 位环境操作系统，如 Linux。所需的条件是供给 64 位机器的编译器（通常是 gcc）。目前大部分 64 位版本的驱动程序还不能用，由于缺少可用的驱动程序，所以使用 64 位操作系统会有挫折。
因为设备的驱动程序通常执行于操作系统内核（kernel）的内部，有可能以 32 位进程执行内核，同时支持 64 位的使用者进程。以在内核里的额外消耗为代价，如此可为使用者提供受益于 64 位的内存和效能，且不破坏现存 32 位驱动程序的二进制兼容性。这个机制源于 Mac OS X 启用 64 位进程，同时支持 32 位的驱动程序。
从 32位到 64 位架构的改变是一个根本的改变，因为大多数操作系统必须进行全面性修改，以取得新架构的优点。其它软件也必须进行移植，以使用新的性能；较旧的软件一般可借由硬件兼容模式（新的处理器支持较旧的 32 位版本指令集）或软件模拟进行支持。或者直接在 64 位处理器里面实作 32 位处理器内核（如同 Intel 的 Itanium 处理器，其内含有 x86 处理器内核，用来执行 32 位 x86 应用程序）。支持 64 位架构的操作系统，一般同时支持 32 位和 64 位的应用程序。
明显的例外是 AS/400，其软件执行在虚拟的指令集架构，称为 TIMI（技术独立机器界面），它会在执行之前，以低阶软件转换成本地机器码。低阶软件必须全部重写，以搬移整个 OS 以及所有的软件到新的平台。例如，当 IBM 转移较旧的 32/48 位“IMPI”指令集到 64 位 PowerPC（IMPI 完全不像 32 位 PowerPC，所以这比从 32 位版本的指令集转移到相同指令集的 64 位版本的规模还要庞大）。
64 位架构无疑可应用在需要处理大量数据的应用程序，如数码视频、科学运算、和早期的大型数据库。在其它工作方面，其 32 位兼容模式是否会快过同等级的 32 位系统，这部分已有很多争论。在 x86-64 架构（AMD64 和 Intel 64）中，主要的 32 位操作系统和应用程序，可平滑的执行于 64 位硬件上。
Sun 的 64 位 Java虚拟机的启动速度比 32 位虚拟机还慢，因为 Sun 仍假定所有的 64 位机器都是服务器，而且只有为 64 位平台实作“服务器”编译器（C2）。“客户端”编译器（C1）产生较慢的代码，不过编译较快速。所以尽管在 64 位 JVM 的 Java 程序在一段很长的周期会执行的较好（一般为长时间运作的“服务器”应用程序），它的启动时间可能更久。对于短生命期的应用程序（如 Java 编译器 javac） 增加启动时间可控制执行时间，使 64 位的 JVM 整体变慢。
应当指出，在比较 32 位和 64 位处理器时，速度并不是唯一的考量因素。应用程序，如多任务、应力测试（stress testing）、丛集（clustering）（用于HPC）可能更适合 64 位架构以正确部署。为了以上原因，64 位丛集已广泛部署于大型组织，如 IBM、Vodafone、HP、微软。
是否可以解决您的问题？
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
