尽管C语言“接近”于对8位、16位、32位和64位数据的低级操作，但仍有一些C语言不支持的数学操作通常可以在某些汇编指令集中优雅地执行:

Fixed-point multiplication: The product of two 16-bit numbers is a 32-bit number. But the rules in C says that the product of two 16-bit numbers is a 16-bit number, and the product of two 32-bit numbers is a 32-bit number -- the bottom half in both cases. If you want the top half of a 16x16 multiply or a 32x32 multiply, you have to play games with the compiler. The general method is to cast to a larger-than-necessary bit width, multiply, shift down, and cast back: int16_t x, y; // int16_t is a typedef for "short" // set x and y to something int16_t prod = (int16_t)(((int32_t)x*y)>>16);` In this case the compiler may be smart enough to know that you're really just trying to get the top half of a 16x16 multiply and do the right thing with the machine's native 16x16multiply. Or it may be stupid and require a library call to do the 32x32 multiply that's way overkill because you only need 16 bits of the product -- but the C standard doesn't give you any way to express yourself. Certain bitshifting operations (rotation/carries): // 256-bit array shifted right in its entirety: uint8_t x[32]; for (int i = 32; --i > 0; ) { x[i] = (x[i] >> 1) | (x[i-1] << 7); } x[0] >>= 1; This is not too inelegant in C, but again, unless the compiler is smart enough to realize what you are doing, it's going to do a lot of "unnecessary" work. Many assembly instruction sets allow you to rotate or shift left/right with the result in the carry register, so you could accomplish the above in 34 instructions: load a pointer to the beginning of the array, clear the carry, and perform 32 8-bit right-shifts, using auto-increment on the pointer. For another example, there are linear feedback shift registers (LFSR) that are elegantly performed in assembly: Take a chunk of N bits (8, 16, 32, 64, 128, etc), shift the whole thing right by 1 (see above algorithm), then if the resulting carry is 1 then you XOR in a bit pattern that represents the polynomial.

尽管如此，除非有严重的性能限制，否则我不会求助于这些技术。正如其他人所说，汇编代码比C代码更难记录/调试/测试/维护:性能的提高伴随着一些严重的代价。

编辑:3。溢出检测在汇编中是可能的(在C中不能真正做到)，这使得一些算法更容易。

在历史上插话。

当我还年轻的时候(20世纪70年代)，根据我的经验，汇编是很重要的，更重要的是代码的大小，而不是代码的速度。

如果一个高级语言的模块是1300字节的代码，但该模块的汇编版本是300字节，那么当您试图将应用程序装入16K或32K的内存时，这1K字节就非常重要。

那时候编译器还不是很好。

在老式的Fortran中

X = (Y - Z)
IF (X .LT. 0) THEN
 ... do something
ENDIF

当时的编译器在X上执行了一个SUBTRACT指令，然后是一个TEST指令。 在汇编程序中，您只需在减法之后检查条件代码(LT零，零，GT零)。

对于现代系统和编译器来说，这些都不是问题。

我认为理解编译器在做什么仍然很重要。 当您使用高级语言编写代码时，您应该了解什么允许或阻止编译器执行循环展开。

当编译器执行“类似分支”的操作时，使用管道内衬和包含条件的前瞻计算。

当执行高级语言不允许的事情时，仍然需要汇编程序，比如读取或写入处理器特定的寄存器。

但在很大程度上，普通程序员不再需要它，除非对代码如何编译和执行有基本的了解。

不需要给出任何具体的示例或分析器证据，当您比编译器知道的更多时，您可以编写比编译器更好的汇编程序。

In the general case, a modern C compiler knows much more about how to optimize the code in question: it knows how the processor pipeline works, it can try to reorder instructions quicker than a human can, and so on - it's basically the same as a computer being as good as or better than the best human player for boardgames, etc. simply because it can make searches within the problem space faster than most humans. Although you theoretically can perform as well as the computer in a specific case, you certainly can't do it at the same speed, making it infeasible for more than a few cases (i.e. the compiler will most certainly outperform you if you try to write more than a few routines in assembler).

另一方面，有些情况下编译器没有那么多的信息——我想说主要是在使用不同形式的外部硬件时，编译器不知道这些信息。主要的例子可能是设备驱动程序，其中汇编程序结合人类对相关硬件的熟悉知识可以产生比C编译器更好的结果。

其他人提到了特殊用途指令，这就是我在上面一段中所说的——编译器可能对这些指令了解有限或根本不了解，这使得人类可以编写更快的代码。

只有在使用编译器不支持的特殊用途指令集时。

为了最大限度地利用具有多个管道和预测分支的现代CPU的计算能力，您需要以这样一种方式来构造汇编程序:a)人类几乎不可能编写b)甚至更不可能维护。

此外，更好的算法、数据结构和内存管理将为您提供至少一个数量级的性能，而不是在汇编中进行的微观优化。

长波克，只有一个限制时间。当你没有足够的资源来优化每一个代码的变化，并花时间分配寄存器，优化一些溢出和诸如此类的事情时，编译器每次都会赢。对代码进行修改、重新编译和度量。如有必要重复。

此外，你可以在高水平方面做很多事情。此外，检查生成的程序集可能会给人一种代码是垃圾的印象，但实际上它的运行速度比您想象的要快。例子:

Int y = data[i]; //在这里做一些事情。 call_function (y,…);

编译器将读取数据，将其推入堆栈(溢出)，然后从堆栈读取并作为参数传递。听起来屎?它实际上可能是非常有效的延迟补偿，并导致更快的运行时。

//优化版本 call_function(数据[我],…);//毕竟不是那么优化。

优化版本的想法是，我们降低了寄存器压力，避免溢出。但事实上，“垃圾”版本更快!

看看汇编代码，只看指令，然后得出结论:指令越多，速度越慢，这将是一个错误的判断。

这里需要注意的是:许多组装专家认为他们知道很多，但知道的很少。规则也会随着架构的变化而变化。例如，x86代码并不存在总是最快的银弹。如今，最好还是按照经验法则行事:

记忆很慢 缓存速度快 尽量更好地使用缓存 你多久会错过一次?你有延迟补偿策略吗? 对于一个cache miss，你可以执行10-100个ALU/FPU/SSE指令 应用程序架构很重要。 . .但是当问题不在架构上时，它就没有帮助了

此外，过于相信编译器会神奇地将考虑不周到的C/ c++代码转换为“理论上最优”的代码是一厢情愿的想法。如果你关心这个低级别的“性能”，你必须知道你使用的编译器和工具链。

C/ c++中的编译器通常不太擅长重新排序子表达式，因为对于初学者来说，函数有副作用。函数式语言没有受到这个警告的影响，但它不太适合当前的生态系统。有一些编译器选项可以允许宽松的精确规则，允许编译器/链接器/代码生成器改变操作的顺序。

这个话题有点死路一条;对于大多数人来说，这是无关紧要的，而剩下的人，他们已经知道自己在做什么了。

这一切都归结为:“理解你在做什么”，这与知道你在做什么有点不同。

第一点不是答案。 即使你从来没有用它编程，我发现至少知道一个汇编指令集是有用的。这是程序员永无止境的追求的一部分，他们想知道得更多，从而变得更好。当你进入一个没有源代码的框架时，它也很有用，至少对正在发生的事情有一个粗略的了解。它还可以帮助您理解JavaByteCode和. net IL，因为它们都类似于汇编程序。

To answer the question when you have a small amount of code or a large amount of time. Most useful for use in embedded chips, where low chip complexity and poor competition in compilers targeting these chips can tip the balance in favour of humans. Also for restricted devices you are often trading off code size/memory size/performance in a way that would be hard to instruct a compiler to do. e.g. I know this user action is not called often so I will have small code size and poor performance, but this other function that look similar is used every second so I will have a larger code size and faster performance. That is the sort of trade off a skilled assembly programmer can use.

我还想补充一点，这里有很多中间地带，您可以用C编译代码并检查生成的程序集，然后更改C代码或调整并作为程序集进行维护。

我的朋友从事微控制器的工作，目前是用于控制小型电动机的芯片。他在低级c和汇编的组合中工作。他曾经告诉我，有一天他在工作中把主循环从48条指令减少到43条。他还面临着各种选择，比如代码已经增长到填满256k芯片，业务需要一个新功能，你呢

删除现有功能 减少部分或全部现有特性的大小，可能会以性能为代价。 提倡改用成本更高、功耗更高、外形更大的更大芯片。

我想补充一点，作为一个商业开发人员，我有很多的投资组合或语言、平台、应用程序类型，我从来没有觉得有必要深入编写程序集。我一直都很感激我所学到的知识。有时会被调试进去。

我知道我已经回答了“为什么我要学习汇编器”这个问题，但我觉得这是一个更重要的问题，而不是什么时候更快。

所以让我们再试一次 你应该考虑组装

致力于底层操作系统功能 在编译器上工作。 工作在一个极其有限的芯片，嵌入式系统等

记住比较你的程序集和生成的编译器，看看哪个更快/更小/更好。

大卫。