内联汇编是否会影响可移植性？
假设您编写了可移植的 C++ 代码，该代码可以在不同平台上顺利运行。要进行一些修改以优化性能，您可以在代码中使用内联汇编。这是一个好的实践（编译器优化放在一边）还是会给可移植性带来麻烦？
Suppose you've written a portable C++ code which runs smoothly on different platforms. To make some modifications to optimize performance, you use inline assembly inside your code. Is it a good practice (compiler optimization set aside) or will it make troubles for portability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
显然它破坏了可移植性——代码只能在汇编语言所针对的特定体系结构上运行。而且，这通常是浪费时间 - 编译器的优化器几乎肯定比您更擅长编写汇编代码。
Obviously it breaks portability - the code will only work on the specific architecture the assembly language is for. Also, it's normally a waste of time - the compiler's optimiser is almost certainly better at writing assembler code than you are.
显然，内联汇编还远远不够便携。为了保持可移植性，您通常必须使用
#ifdef（或类似的命令）来确定何时使用它。我自己的偏好是将汇编语言分离到一个单独的文件中，并在 makefile 中决定是构建可移植版本还是汇编语言版本。
Obviously the inline assembly isn't even close to portable. To maintain any portability at all, you generally have to use an
#ifdef(or something on that order) to determine when to use it at all.My own preference is to segregate the assembly language into a separate file, and in the makefile decide whether to build the portable version or the assembly language version.
这取决于。
如果您只有 x86 程序集，您的应用程序将永远无法在 ARM 和本机 x64 上运行。为了解决这个问题，您可以根据架构用 #ifdef 包围它。这是跨平台、高度优化的库（例如 h264）使用的方法。但在大多数情况下，这是不值得的。只需使用非常特定的 C，它的行为就与本机汇编非常相似。
It depends.
If you have only x86 assembly, your application won't ever run on ARM and native x64. To solve this, you can surround it with #ifdef's depending on the architecture. This is the approach cross-platform, highly optimized libraries such as h264 use. In most cases, though, it's not worth it. Just use very specific C and it will behave very similarly to native assembly.
另一个明显的选择是仅在某些体系结构上实现内联汇编，并为任何其他体系结构保留原始（未优化的）C++，而不是尝试为所有体系结构生成汇编。 （当然，#ifdefed 是合适的。）然后，您将受益于单一架构的优化，以及所有基本功能。
然而，当我们在我过去从事过的项目上执行此操作时，这是最难维护的部分 - 其他一些代码会发生变化，并且传递到隔离函数中的确切内容也会发生变化，原来的C++和汇编就不再匹配了，大家都在哀嚎切齿。
The other obvious choice is to only implement inline assembly on certain architectures, and keep the original (unoptimized) C++ for any other architecture, rather than trying to generate assembly for all architectures. (Suitably #ifdefed, of course.) Then you get the benefit of the optimization on the one architecture, with the basic functionality on all.
However, when we've done this on projects I've worked on in the past, this was the worst part to maintain - some other piece of code would change, and exactly what was being passed into the isolated function(s) would change, and the original C++ and assembly wouldn't match any more, and there was much wailing and gnashing of teeth.