64 位应用程序和内联汇编

Question

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

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

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

Answer 1

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

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

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

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

由于性能不是我的应用程序关心的问题，因此使用额外的 64 位寄存器对我来说不是问题。 32位应用程序将来必须升级到64位还有其他原因吗？

64位与寄存器无关。 它与可寻址虚拟 memory 的大小有关。

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

此外，对于手动编码的组装速度较慢：

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

无论 M$ 说什么，汇编都可以在需要高度优化的代码中占有一席之地。 在您尝试之前，您不会真正知道汇编是否会加速代码。 其他一切都只是自以为是。

如上所述，我赞成将 c++ 代码编译成汇编，然后手动优化的方法。 它省去了你写很多东西的麻烦； 并且通过一些实验，您可能会得到更快测试出来的东西。 FWIW，我从来不需要现代程序。 通常，其他东西可以加快速度，例如多线程，使用查找表，将耗时的操作移出循环，使用 static 分析器，使用实时分析器，如 valgrind（如果您使用的是 Linux）等。但是，对于性能关键型应用程序，我认为没有理由不尝试； 如果它有效，就使用它。 M$ 只是通过删除内联汇编来偷懒。

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

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

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

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