C语言常常需要做一些从汇编编码员的角度看来不必要的事情，这只是因为C标准这么说。

例如，整数提升。如果你想在C语言中移动一个char变量，人们通常会期望代码实际上只做一个比特的移动。

然而，标准强制编译器在移位之前将符号扩展为int，然后将结果截断为char，这可能会使代码复杂化，这取决于目标处理器的架构。

只要有合适的程序员，汇编程序总是可以比C程序快(至少稍微快一点)。如果不能从汇编器中取出至少一条指令，则很难创建一个C程序。

C语言常常需要做一些从汇编编码员的角度看来不必要的事情，这只是因为C标准这么说。

例如，整数提升。如果你想在C语言中移动一个char变量，人们通常会期望代码实际上只做一个比特的移动。

然而，标准强制编译器在移位之前将符号扩展为int，然后将结果截断为char，这可能会使代码复杂化，这取决于目标处理器的架构。

下面是一个真实的例子:固定点在旧编译器上进行乘法运算。

这些不仅在没有浮点数的设备上很方便，在精度方面也很出色，因为它们可以提供32位精度和可预测的错误(浮点数只有23位，很难预测精度损失)。即在整个范围内均匀的绝对精度，而不是接近均匀的相对精度(浮点数)。

---

现代编译器很好地优化了这个定点示例，因此对于仍然需要特定于编译器的代码的更现代的示例，请参见

获得64位整数乘法的高部分:使用uint64_t for 32x32 => 64位乘法的便携版本在64位CPU上无法优化，因此你需要intrinsic或__int128来在64位系统上实现高效的代码。 Windows 32位上的_umul128: MSVC在将32位整数转换为64时并不总是做得很好，因此intrinsic有很大帮助。

---

C语言没有完整的乘法运算符(由n位输入产生2n位)。在C语言中表达它的通常方法是将输入转换为更宽的类型，并希望编译器能够识别输入的上半部分是不有趣的:

// on a 32-bit machine, int can hold 32-bit fixed-point integers.
int inline FixedPointMul (int a, int b)
{
  long long a_long = a; // cast to 64 bit.

  long long product = a_long * b; // perform multiplication

  return (int) (product >> 16);  // shift by the fixed point bias
}

这段代码的问题在于，我们做了一些不能直接用c语言表达的事情。我们希望将两个32位的数字相乘，得到一个64位的结果，并返回中间的32位。然而，在C语言中这个乘法是不存在的。您所能做的就是将整数提升为64位，并执行64*64 = 64乘法。

x86(以及ARM、MIPS和其他)可以在一条指令中完成乘法运算。一些编译器过去常常忽略这一事实，并生成调用运行时库函数来进行相乘的代码。移位到16也经常由库例程完成(x86也可以做这样的移位)。

所以我们只剩下一两个乘法库调用。这造成了严重的后果。不仅移位速度较慢，而且在整个函数调用中必须保留寄存器，而且对内联和展开代码也没有帮助。

如果你在(内联)汇编器中重写相同的代码，你可以获得显著的速度提升。

除此之外:使用ASM并不是解决问题的最佳方法。大多数编译器允许你以内在的形式使用一些汇编指令，如果你不能用c语言表达它们。例如，VS.NET2008编译器将32*32=64位的mul公开为__emul，将64位的移位公开为__ll_rshift。

使用intrinsic，你可以以一种c编译器有机会理解发生了什么的方式重写函数。这允许代码内联，寄存器分配，公共子表达式消除和常量传播也可以完成。与手工编写的汇编程序代码相比，您将获得巨大的性能改进。

供参考:VS.NET编译器的定点mul的最终结果是:

int inline FixedPointMul (int a, int b)
{
    return (int) __ll_rshift(__emul(a,b),16);
}

定点除法的性能差异更大。通过编写几行asm代码，我对除法重的定点代码进行了10倍的改进。

---

使用Visual c++ 2013为这两种方式提供了相同的汇编代码。

2007年的gcc4.1也很好地优化了纯C版本。(Godbolt编译器资源管理器没有安装任何早期版本的gcc，但即使是较旧的gcc版本也可以在没有intrinsic的情况下做到这一点。)

在Godbolt编译器资源管理器上查看用于x86(32位)和ARM的source + asm。(不幸的是，它没有任何旧到足以从简单的纯C版本生成糟糕代码的编译器。)

---

现代cpu可以做一些C语言根本没有操作符的事情，比如popcnt或位扫描来查找第一个或最后一个设置位。POSIX有一个ffs()函数，但是它的语义不匹配x86 bsf / bsr。见https://en.wikipedia.org/wiki/Find_first_set)。

一些编译器有时可以识别一个计数整数中设置位数的循环，并将其编译为popcnt指令(如果在编译时启用)，但在GNU C中使用__builtin_popcnt要可靠得多，或者在x86上(如果你的目标硬件是SSE4.2: _mm_popcnt_u32 from < immintrinh >)。

或者在c++中，赋值给std::bitset<32>并使用.count()。(在这种情况下，该语言已经找到了一种方法，可以通过标准库可移植地公开popcount的优化实现，以一种总是编译为正确的方式，并且可以利用目标支持的任何东西。)参见https://en.wikipedia.org/wiki/Hamming_weight#Language_support。

类似地，ntohl可以在一些具有它的C实现上编译为bswap(用于端序转换的x86 32位字节交换)。

---

intrinsic或手写asm的另一个主要领域是使用SIMD指令进行手工向量化。编译器对于dst[i] += src[i] * 10.0;这样的简单循环并不糟糕，但是当事情变得更复杂时，编译器通常做得很糟糕，或者根本不自动向量化。例如，你不太可能得到任何像如何实现atoi使用SIMD?由编译器从标量代码自动生成。

在我的工作中，有三个原因让我了解和使用组装。按重要性排序:

Debugging - I often get library code that has bugs or incomplete documentation. I figure out what it's doing by stepping in at the assembly level. I have to do this about once a week. I also use it as a tool to debug problems in which my eyes don't spot the idiomatic error in C/C++/C#. Looking at the assembly gets past that. Optimizing - the compiler does fairly well in optimizing, but I play in a different ballpark than most. I write image processing code that usually starts with code that looks like this: for (int y=0; y < imageHeight; y++) { for (int x=0; x < imageWidth; x++) { // do something } } the "do something part" typically happens on the order of several million times (ie, between 3 and 30). By scraping cycles in that "do something" phase, the performance gains are hugely magnified. I don't usually start there - I usually start by writing the code to work first, then do my best to refactor the C to be naturally better (better algorithm, less load in the loop etc). I usually need to read assembly to see what's going on and rarely need to write it. I do this maybe every two or three months. doing something the language won't let me. These include - getting the processor architecture and specific processor features, accessing flags not in the CPU (man, I really wish C gave you access to the carry flag), etc. I do this maybe once a year or two years.

这很难具体地回答，因为这个问题非常不具体:到底什么是“现代编译器”?

理论上，几乎任何手动的汇编器优化都可以由编译器来完成——实际上它是否已经完成，不能笼统地说，只能说特定编译器的特定版本。许多可能需要花费大量的精力来确定它们是否可以在特定的上下文中应用而不产生副作用，以至于编译器编写者不会为它们烦恼。