64位应用程序和内联汇编

64bit Applications and Inline Assembly

本文关键字：汇编 应用程序 64位      更新时间：2023-10-16

我正在使用Visual C++2010开发32位windows应用程序。我真的很想使用内联汇编。但我刚刚意识到visual C++不支持64位应用程序中的内联汇编。因此，将来移植到64位是一个大问题。

我不知道64位应用程序和32位应用程序有什么不同。未来是否有可能将32位应用程序全部升级到64位？我听说64位CPU有更多的寄存器。由于我的应用程序不关心性能，所以我不关心使用这些额外的寄存器。32位应用程序需要升级到64位还有其他原因吗？与32位应用程序相比，64位应用程序的处理方式会有所不同吗？除了64位应用可能使用64位CPU独有的寄存器或指令之外？

我的应用程序需要与其他操作系统组件交互，例如驱动程序，我知道这些组件在64位窗口中必须是64位的。我的32位应用程序与它们兼容吗？

Visual C++不支持x64（或ARM）处理器的内联汇编，因为通常使用内联汇编是个坏主意。

  1. 通常编译器产生比人类更好的汇编
  2. 即使您可以生成比编译器更好的程序集，使用内联程序集通常也会击败任何类型的代码优化器。当然，手工优化的代码可能会更快，但它周围的代码无法优化的事实通常会导致整个程序的速度变慢
  3. 几乎所有主要编译器都提供编译器内部函数，这些编译器允许您以与C和C++语言一致的方式访问高级CPU功能（例如SSE），并且不会破坏优化器

我想知道未来是否有机会将32位应用程序全部升级到64位。

这取决于你的目标受众。如果你的目标是服务器，那么是的，允许用户不安装WOW64子系统是合理的，因为它是一个服务器——你知道它可能不会运行太多32位代码。我相信，如果您将其作为"服务器核心"实例安装，Windows Server 2008 R2已经允许将其作为一个选项。

由于性能不是我的应用程序的问题，所以使用额外的64位寄存器也不是我的问题。有没有其他原因导致32位应用程序将来必须升级到64位？

64位与寄存器无关。这和可寻址虚拟内存的大小有关。

除了64位应用程序使用一些64位CPU独有的寄存器/指令之外，64位应用进程是否与32位应用程序进程不同？

很有可能。32位应用程序受到限制，因为它们不能一次将超过2GB的内容映射到内存中。64位应用程序没有这个问题。即使他们使用的物理内存不超过4GB，能够寻址超过4GB的虚拟内存也有助于将磁盘上的文件映射到内存等。

我的应用程序需要与其他操作系统组件交互，例如驱动程序，我知道这些组件在64位窗口中必须是64位的。我的32位应用程序与它们兼容吗？

这完全取决于你如何与这些司机沟通。如果它是通过类似"命名文件接口"的东西，那么你的应用程序可以保持为32位。如果你试图做一些类似共享内存的事情（哎呀！通过驱动程序从用户模式访问共享内存？！？），那么你必须将你的应用程序构建为64位。

除了@Billy的精彩文章外，如果你真的觉得有必要使用64位汇编，那么你可以使用像MASM这样的外部汇编程序来完成这项工作，请参阅下文。（也可以通过预构建脚本来加快速度）。

"英特尔C编译器15"也具有64位的内联功能。你可以在Visual Studio中将IC集成为一个工具集：然后你就有了带有内联汇编的VC++64位。不过有一个陷阱——价格昂贵欢呼

当我们在做它的时候，MinGW也有64位内联汇编语言；而且速度很快，而且免费。它过去在一些数学方面很慢；所以我会先比较MSVC和MinGW的性能，看看它是否是您应用程序的一个不错的起点。

此外，关于手动编码组件的速度较慢：

  1. 事实上，人类经常进行比编译器更高效的代码汇编——或者至少这一直是我在70年代和80年代学习编程时的普遍智慧，并一直延续到2000年
  2. 你总是可以用"；C"；或者C++，将编译为汇编，并对其进行调整，看看是否可以改进。这样，您就可以从优化中学习和看看你是否可以改进它们

无论M$怎么说，汇编在需要高度优化的代码中都有很大的位置。在尝试之前，您不会真正知道程序集是否会加速代码。其他一切都只是高谈阔论。

如上所述，我喜欢将c++代码编译成程序集，然后手动优化它的方法。它省去了你写大部分内容的麻烦；通过一点实验，你可能会得到更快的测试结果。FWIW，我从来没有需要一个现代化的程序。通常，其他事情可以加快它的速度，例如多线程、使用查找表、将耗时的操作移出循环、使用静态分析器、使用valgrind等实时分析器（如果你在Linux上）等。然而，对于性能关键的应用程序，我认为没有理由不尝试；只要有效就用它。M$只是因为删除了内联程序集而变得懒惰。

至于是64位还是32位更快，这与16位与32位的情况类似。更宽的带宽可以更快地传输大量数据。如果两者都运行在64位操作系统上，那么它们的运行速度完全相同；所以32位程序不应该更快。然而，我观察到32位Win7的CPU时钟运行速度略快于64位Win7。因此，对于相同数量的线程和CPU密集型操作，32位Win7上的32位应用程序会更快。然而，差别并不大；64位指令确实可以发挥作用。但是，给定的用户将只安装一个操作系统；因此，对于该操作系统来说，64位应用程序将更快；或者如果在64位操作系统上运行32位应用程序，则速度最好相同。然而，这将是一个更大的下载量。您还可以选择64位的可能更快的速度；除非您正在处理一个运行代码的专用系统，否则您知道该系统不会移动大量数据。

此外，请注意，我使用各自版本的MinGW，在不同大小的操作系统上对64位和32位应用程序进行了基准测试。它做了很多64位浮点运算，我确信64位版本会有优势。它没有！！我的猜测是，内置数学协处理器中的浮点寄存器在两个操作系统上都以相同数量的时钟周期运行，在64位Win7上可能会稍微慢一点。我的基准测试在两个版本中都非常接近，所以其中一个版本的速度并不明显更快。也许长时间的数字运算在64位上较慢，但64位程序代码运行得更快，结果几乎相同。

基本上，32位唯一有意义的时候，IMHO，是当你认为你可能有一个在32位操作系统上运行更快的内部应用程序时；你想要一个非常小的可执行文件，或者当你在32位操作系统机器上向用户交付时（许多开发人员仍然提供这两个版本），或者32位嵌入式系统。

编辑以反映我的一些评论与我使用Win7 x86与x64的具体经验有关。

相关文章：