64 位应用程序和内联汇编

Question

我正在使用 Visual C++ 2010 开发 32 位 Windows 应用程序。有些东西我真的很想使用内联汇编。但我刚刚意识到，Visual C++ 不支持 64 位应用程序中的内联汇编。所以未来移植到64位是个大问题。

我不知道 64 位应用程序与 32 位应用程序有何不同。未来 32 位应用程序是否有可能全部升级到 64 位？我听说 64 位 CPU 有更多的寄存器。由于性能不是我的应用程序关心的问题，因此使用这些额外的寄存器对我来说不是一个问题。是否还有其他原因需要将 32 位应用程序升级到 64 位？除了 64 位应用程序可能使用 64 位 CPU 独有的寄存器或指令之外，64 位应用程序与 32 位应用程序处理事情是否会有所不同？

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

Answer 1

Visual C++ does not support inline assembly for x64 (or ARM) processors，因为通常使用内联汇编是个坏主意。

1. 通常编译器产生比人类更好的汇编。
2. 即使您可以生成比编译器更好的汇编程序，使用内联汇编程序通常也会击败任何类型的代码优化器。当然，您手动优化的代码可能会更快，但无法优化它周围的代码通常会导致整个程序变慢。
3. Compiler intrinsics 可从几乎所有主要编译器中获得，让您以与 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 位 Windows 中必须是 64 位。我的 32 位应用程序会与它们兼容吗？

这完全取决于您与这些司机的沟通方式。如果它通过类似“命名文件接口”的方式，那么您的应用程序可以保持为 32 位。如果您尝试执行共享内存之类的操作（哎呀！可以通过驱动程序从用户模式访问共享内存？！？），那么您将不得不将您的应用程序构建为 64 位。

Answer 2

除了@Billy 的精彩文章之外，如果您真的觉得需要使用 64 位汇编，那么您可以使用像 MASM 这样的外部汇编器来完成这项工作，see this。 （也可以使用预构建脚本加快速度）。

Answer 3

英特尔 C 编译器 15 也具有 64 位的内联功能。 您可以将 IC 作为工具集集成到 Visual Studio 中：然后您将拥有 VC++ 64 位和内联汇编。 虽然有一个问题 - 它很贵 干杯

Answer 4

虽然我们正在使用它，但 MinGW 还具有 64 位内联汇编语言；而且速度很快，而且免费。它曾经在一些数学上很慢；所以我会开始比较 MSVC 与 MinGW 的性能，看看它是否适合您的应用程序。

另外，关于手工编码的组装速度较慢：

1. 实际上，人类经常进行比编译器更高效的代码汇编 - 或者至少当我在 70 年代和 80 年代学习编程时，这一直是普遍的看法，并且一直持续到 2000 年左右。
2. 您始终可以使用“C”或 C++ 对其进行编码，将 that 编译为程序集，然后对其进行调整以查看是否可以改进它。这样，您可以从优化中学习； 和看看你是否可以改进它们。

无论 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 位唯一有意义的时候是当您认为您可能拥有一个在 32 位操作系统上运行得更快的内部应用程序时；您想要一个非常小的可执行文件，或者当您在 32 位操作系统机器（许多开发人员仍然提供这两个版本）或 32 位嵌入式系统上交付给用户时。

已编辑以反映我的一些评论与我在 Win7 x86 与 x64 方面的具体经验有关。