64位应用程序和内联汇编

Question

我正在使用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位应用程序是否与它们兼容？

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位窗口必须是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 $只是懒惰。