在 CC++ 中使用汇编语言

恢复到汇编语言唯一有用的时候是

• CPU指令在C++中没有功能上的类似功能(例如单指令多数据指令、BCD或十进制算术运算)

  • 并且编译器不提供额外的函数来包装这些运算(例如，C++11标准中有atomic operations个函数，包括compare-and-swap、<cstdlib>和div/ldiv等，用于高效地获得商and的余数)
  • 而且没有好的第三方库(例如http://mitpress.mit.edu/catalog/item/default.asp?tid=3952&ttype=2)

  OR

• 由于某种莫名其妙的原因-优化器没有使用最佳的CPU指令

...AND...

• 这些CPU指令的使用将给瓶颈代码带来一些显著而有用的性能提升.

简单地使用内联汇编来做一个操作，它可以很容易地用C++来表达，比如添加两个值或者在字符串中搜索，这是积极的反作用，因为:

• 编译器同样知道如何做到这一点.
  • 要验证这一点，请查看其汇编输出(例如gcc -S)或反汇编机器代码
• you're artificially restricting its choices regarding register allocation, CPU instructions etc., so it may take longer to prepare the CPU registers with the values needed to execute your hardcoded instruction, then longer to get back to an optimal allocation for future instructions
  • 编译器优化器可以在指定不同寄存器的等价性能指令之间进行 Select ，以最小化它们之间的复制，并且可以这样的方式 Select 寄存器，即单个内核可以在一个周期内处理多条指令，而强制通过特定寄存器执行所有操作将使其序列化.
    • 公平地说，GCC有办法表达对特定类型寄存器的需求，而不会将cpu限制到确切的寄存器，仍然允许这样的优化，但这是我见过的唯一解决这一问题的内联汇编
• 如果明年新的CPU型号推出另一条指令，该指令对于相同的逻辑操作要快1000%，那么编译器供应商更有可能更新他们的编译器以使用该指令，从而使您的程序在重新编译后受益，而不是您(或当时的软件维护人员)
• 编译器将为它所讲述的目标体系 struct Select 一种最佳方法:如果您硬编码一个解决方案，那么它将需要是最低公分母的解决方案，或者是适用于您的平台的#ifdef版解决方案
• 汇编语言不像C++那样可移植，无论是跨CPU还是跨编译器，而且即使您似乎移植了一条指令，也有可能犯错误，重新寄存器是安全的，参数传递约定等等.
• 其他程序员可能不知道或不熟悉汇编语言

我认为值得记住的一个观点是，当C被引入时，它必须赢得许多对生成的机器代码大惊小怪的汇编语言程序员的支持.当时机器的CPU能力和RAM较少，你可以打赌人们会对最微小的事情大惊小怪.优化器变得非常复杂，并且还在不断改进，而x86等处理器的汇编语言变得越来越复杂，它们的执行流水线、缓存和其他影响其性能的因素也变得越来越复杂.您不能再仅仅从每条指令的周期表中添加值了.编译器编写人员花时间考虑所有这些微妙的因素(特别是那些为CPU制造商工作的因素，但这也增加了其他编译器的压力).现在，汇编语言程序员要在任何重要的应用程序中平均出比优秀优化编译器生成的代码效率高得多的代码效率是不切实际的，而且他们极有可能做得更差.因此，组装的使用应该限制在它真正产生可测量和有用的差异的时候，值得耦合和维护成本.