64 位应用程序和内联汇编 [英] 64bit Applications and Inline Assembly

问题描述

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

解决方案

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

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 位 Windows 中必须是 64 位.我的 32 位应用程序是否与它们兼容?

这完全取决于您与这些驱动程序的沟通方式.如果它是通过命名文件接口"之类的东西，那么您的应用程序可以保持为 32 位.如果您尝试执行诸如共享内存之类的操作(哎呀！可以通过驱动程序从用户模式访问共享内存?！?)，那么您将不得不将您的应用构建为 64 位.

I am using Visual C++ 2010 developing 32bit windows applications. There is something I really want to use inline assembly. But I just realized that visual C++ does not support inline assembly in 64bit applications. So porting to 64bit in the future is a big issue.

I have no idea how 64bit applications are different from 32bit applications. Is there a chance that 32bit applications will ALL have to be upgraded to 64bit in the future? I heard that 64bit CPUs have more registers. Since performance is not a concern for my applications, using these extra registers is not a concern to me. Are there any other reasons that a 32bit application needs to be upgraded to 64bit? Would a 64 bit application process things differently when compared with a 32bit application, apart from that the 64bit applications may use registers or instructions that are unique to 64bit CPUs?

My application needs to interact with other OS components e.g. drivers, which i know must be 64bit in 64bit windows. Would my 32bit application compatible with them?

解决方案

Visual C++ does not support inline assembly for x64 (or ARM) processors, because generally using inline assembly is a bad idea.

1. Usually compilers produce better assembly than humans.
2. Even if you can produce better assembly than the compiler, using inline assembly generally defeats code optimizers of any type. Sure, your bit of hand optimized code might be faster, but the fact that code around it can't be optimized will generally lead to a slower overall program.
3. Compiler intrinsics are available from pretty much every major compiler that let you access advanced CPU features (e.g. SSE) in a manner that's consistent with the C and C++ languages, and does not defeat the optimizer.

I am wondering would there be a chance that 32bit applications will ALL have to be upgraded to 64bit in the future.

That depends on your target audience. If you're targeting servers, then yes, it's reasonable to allow users to not install the WOW64 subsystem because it's a server -- you know it'll probably not be running too much 32 bit code. I believe Windows Server 2008 R2 already allows this as an option if you install it as a "server core" instance.

Since performance is not a concern for my appli so using the extra 64bit registers is not a concern to me. Is there any other reasons that a 32bit appli has to be upgraded to 64bit in the future?

64 bit has nothing to do with registers. It has to do with size of addressable virtual memory.

Would a 64 bit app process different from a 32bit appl process apart from that the 64bit appli is using some registers/instructions that is unique to 64bit CPUs?

Most likely. 32 bit applications are constrained in that they can't map things more than ~2GB into memory at once. 64 bit applications don't have that problem. Even if they're not using more than 4GB of physical memory, being able to address more than 4GB of virtual memory is helpful for mapping files on disk into memory and similar.

My application needs to interact with other OS components e.g. drivers, which i know must be 64bit in 64bit windows. Would my 32bit application compatible with them?

That depends entirely on how you're communicating with those drivers. If it's through something like a "named file interface" then your app could stay as 32 bit. If you try to do something like shared memory (Yikes! Shared memory accessible from user mode with a driver?!?) then you're going to have to build your app as 64 bit.

这篇关于64 位应用程序和内联汇编的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！