汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
汇编在不同的微处理器之间是不可移植的。
其他回答
我猜即使是x86(_64)上的ASM也有意义，因为您可以利用编译器难以优化的指令来获得很多好处。以X264为例，它使用了大量的asm编码，速度增益是巨大的。
汇编在不同的微处理器之间是不可移植的。
随着汇编变得越来越不常见，出现了一个恶性循环:随着高级语言的成熟，汇编语言指令集的构建越来越少地是为了方便程序员，而更多地是为了方便编译器。
So now, realistically, it may be very hard to make the right decisions on, say, which registers you should use or which instructions are slightly more efficient. Compilers can use heuristics to figure out which tradeoffs are likely to have the best payoff. We can probably think through smaller problems and find local optimizations that might beat our now pretty sophisticated compilers, but odds are that in the average case, a good compiler will do a better job on the first try than a good programmer probably will. Eventually, like John Henry, we might beat the machine, but we might seriously burn ourselves out getting there.
Our problems are also now quite different. In 1986 I was trying to figure out how to get a little more speed out of small programs that involved putting a few hundred pixels on the screen; I wanted the animation to be less jerky. A fair case for assembly language. Now I'm trying to figure out how to represent abstractions around contract language and servicer policy for mortgages, and I'd rather read something that looks close to the language that the business folks speak. Unlike LISP macros, Assembly macros don't enforce much in the way of rules, so even though you might be able to get something reasonably close to a DSL in a good assembler, it'll be prone to all sorts of quirks that won't cause me problems if I wrote the same code in Ruby, Boo, Lisp, C# or even F#.
如果您的问题很容易用高效的汇编语言来表达，那么您的能力就更强了。
如果一个普通的生产程序有10万行代码，每一行大约有8-12条汇编指令，那就是100万条汇编指令。
即使您可以以相当快的速度手写所有这些代码(请记住，这是您必须编写的8倍代码)，如果您想更改某些功能会发生什么?从这100万条指令中理解你几周前写的东西简直是一场噩梦!没有模块，没有类，没有面向对象的设计，没有框架，什么都没有。即使是为最简单的事情编写的类似代码的数量最多也令人生畏。
此外，你不能像高级语言那样优化你的代码。例如，C语言执行了大量的优化，因为你描述了你的意图，不仅仅是你的代码，在汇编程序中你只写代码，汇编程序不能对你的代码执行任何值得注意的优化。你写的就是你得到的，相信我，你不可能可靠地优化100万条指令，你在写的时候不断地打补丁。
早期的发现之一(你可以在布鲁克斯的《神秘的人月》中找到，这是20世纪60年代的经验)是，人们使用一种语言的效率或多或少与使用另一种语言的效率一样高，每天调试的代码行数也差不多。显然，这并不是普遍的事实，如果做得太过分，可能会崩溃，但对于Brooks时代的高级语言来说，这是普遍的事实。
因此，提高工作效率的最快方法是使用一行代码就能做更多工作的语言，这确实有效，至少对于像FORTRAN和COBOL这样复杂的语言，或者给出一个更现代的例子C。
