64位应用程序和内联汇编

Question

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

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

我的应用程序需要与其他OS组件交互，例如驱动程序，我知道64位窗口必须是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的虚拟内存也有助于将磁盘上的文件映射到内存等。

我的应用程序需要与其他OS组件交互，例如驱动程序，我知道64位窗口必须是64位。我的32位应用程序是否与它们兼容？

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

Answer 2

除了@Billy的精彩编写，如果你真的觉得需要使用内联64位汇编，那么你可以使用像MASM这样的外部汇编程序来完成它，see this。 （它也可以通过预建脚本加快速度）。

Answer 3

英特尔C编译器15也具有64位内联功能。并且您可以将Visual Studio中的IC集成为工具集：然后您将拥有带内联汇编的VC ++ 64位。虽然有一个问题，但却是昂贵的欢呼声

Answer 4

虽然我们正在使用它，MinGW也有64位内联汇编语言;它非常快，而且是免费的。在某些数学上它曾经很慢;所以我开始比较MSVC和MinGW的性能，看看它是否适合您的应用程序。

此外，如果内联汇编应该减慢周围的代码;在我看来，虽然许多短片段可能都是如此：

1. 实际上，人类经常进行比编译器运行更高效的代码汇编 - 或者至少在我70年代和80年代学习编程时总是常识，并且在2000年之后仍然如此。
2. 取决于循环中花费的时间和代码量;一个手写的汇编程序可以加快程序运行速度，使得优化失去的性能可能相对较小;或者没有 - 就像将整个函数转换为汇编一样。

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

我赞成将c ++代码编译成汇编的方法，然后手工优化THAT。它可以省去写大部分内容的麻烦;通过一些实验，您可以利用编译器的最佳优化;然后开始改进。 FWIW，我从来不需要现代计划。通常情况下，其他事情可以加快速度 - 例如比如多线程。但是，对于性能关键型应用程序，我认为没有理由不尝试;只要它有用就可以使用它。 M $只是懒惰。