64位应用程序和内联汇编

Jav*_*Man 27 c++ windows 64-bit inline-assembly visual-c++

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

Bil*_*eal 18

Visual C++不支持x64模式的内联汇编,因为通常使用内联汇编是个坏主意.

  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位.如果您尝试执行共享内存(Yikes!共享内存可从用户模式访问驱动程序?!?),那么您将不得不将应用程序构建为64位.

  • 我真的很抱歉碰到这个,但是......无论是谁(微软)决定不在x64中包含内联汇编,因为它"通常是一个坏主意"应该在视线中拍摄.我是程序员,让我面对你(微软)假设我要写的坏代码的后果. (46认同)
  • 我不同意你说64位与寄存器无关.X64的寄存器是X86的两倍. (14认同)
  • 除了内联装配的速度之外还有其他原因 (9认同)
  • 当我切换到x64时,他们肯定会失去一个客户.这是我的应用程序,对于我的工作,我*需要*内联汇编(我主要做逆向工程).因此,GCC的另一个客户,一个MSVC客户少一个.只需我5美分. (5认同)
  • 一个更正 - 32位应用程序可以映射〜4GB - 32位声明:)这取决于操作系统,一些额外的限制出现 - 在32位Windows默认情况下你得到2GB但可以使用启动开关获得3GB.我认为在大多数64位系统上,应用程序可以获得4GB的全部内存.另外一个32位操作系统可以处理超过4GB的物理内存:http://msdn.microsoft.com/en-us/library/aa366778(v = vs.85).aspx#physical_memory_limits_windows_server_2003 - WS 2003 x86 == 64 GB (3认同)
  • @AcidShout:好消息是 MSFT 从他们免费赠送的编译器中赚到了所有钱:) (3认同)
  • @Boofhead:是的,x64确实有更多的寄存器.但是更多的寄存器不是人们转向64位的原因.由于地址空间原因,人们正在转向x64.寄存器只是一个奖励. (2认同)
  • @Acid:向拥有编译器的人抱怨,而不是向我抱怨。虽然我碰巧同意这里的编译器人。如果要使用程序集,那么只需编写一个程序集文件。我很高兴他们没有花费开发时间来实现一个前端功能,当存在完美的解决方法时,99.999% 的人不应该使用该功能。 (2认同)
  • *“...因为通常使用内联汇编是一个坏主意”* - 请引用。微软在 [Inline Assembler](https://github.com/MicrosoftDocs/cpp-docs/blob/master/docs/assembler/inline/inline-assembler.md) 列出的唯一缺点是缺乏可移植性。事实上,微软在 [Advantages of Inline Assembly](https://github.com/MicrosoftDocs/cpp-docs/blob/master/docs/assembler/inline/advantages-of-inline-assembly。 MD)。 (2认同)

Nec*_*lis 13

除了@Billy的精彩编写,如果你真的觉得需要使用内联64位汇编,那么你可以使用像MASM这样的外部汇编器来完成它,看看这个.(它也可以通过预建脚本加快速度).


小智 6

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