汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
随着汇编变得越来越不常见，出现了一个恶性循环:随着高级语言的成熟，汇编语言指令集的构建越来越少地是为了方便程序员，而更多地是为了方便编译器。
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#.
如果您的问题很容易用高效的汇编语言来表达，那么您的能力就更强了。
其他回答
我现在正在comp组织学习汇编，虽然它很有趣，但它也非常低效。你必须在脑子里记住更多的细节才能让事情顺利进行，而且写同样的东西也会慢一些。例如，c++中一个简单的6行For循环可以等于18行或更多的汇编。
就我个人而言，学习硬件层面的工作方式非常有趣，它让我对计算的工作方式有了更多的了解。
我喜欢用汇编语言编程，但是用高级语言做同样的事情需要更多的代码，而且代码行和错误之间有直接的联系。(这在几十年前的《人月神话》中就有解释。)
可以把C语言看作是“高级汇编”，但再往上走几步，你就进入了另一个世界。在c#中，你不需要三思就可以写这样的代码:
foreach (string s in listOfStrings) { /* do stuff */ }
这将是几十行，甚至几百行的汇编代码，每个实现它的程序员将采用不同的方法，下一个来的人将不得不找出它。因此，如果您相信(许多人都相信)程序主要是为其他人阅读而编写的，那么汇编的可读性就不如典型的HLL。
编辑:我积累了一个用于常见任务的个人代码库，以及用于实现类c控制结构的宏。但在90年代，当gui成为常态时，我遇到了瓶颈。太多的时间被花在了例行公事上。
我的上一个需要使用ASM的任务是在几年前，编写代码来对抗恶意软件。没有用户界面，所以只有有趣的部分，没有臃肿的部分。
与高级语言相比，ASM的易读性很差，而且实际上难以维护。
此外，ASM开发人员比其他更流行的语言(如C)要少得多。
此外，如果您使用高级语言，并且有新的ASM指令可用(例如SSE)，您只需要更新您的编译器，您的旧代码就可以轻松使用新的指令。
如果下一个CPU有两倍多的寄存器呢?
这个问题的反义词是:编译器提供了什么功能?
我怀疑你能够/想要/应该比gcc -O3更好地优化你的ASM。
因为事情总是这样:时间流逝，美好的东西也会消逝:(
但是当你编写asm代码时，这与编写高级语言的感觉完全不同，尽管你知道它的效率要低得多。这就像你是一个画家:你可以自由地画任何你喜欢的东西，完全没有限制(嗯，只有CPU的功能)……这就是我喜欢它的原因。很遗憾这种语言消失了。但只要有人还记得它并对它进行编码，它就永远不会消亡!
正如其他人之前提到的，任何工具存在的原因都是它的工作效率。由于hll可以完成与许多行asm代码相同的工作，我想汇编被其他语言取代是很自然的。对于接近硬件的操作——有C语言的内联汇编和每种语言的其他变体。 保罗·卡特博士在PC汇编语言中说
＂...更好地理解如何 计算机实际上是在较低的水平上工作的 而不是编程语言 帕斯卡。通过获得更深层次的 了解计算机的工作原理， 读者通常可以做得更多 生产开发软件 高级语言，如C和 c++。学习汇编编程 语言是一种极好的方法 实现这个目标。”
在我的大学课程中有装配入门。这将有助于理清概念。然而，我怀疑我们中是否有人会用汇编编写90%的代码。今天深入的组装知识有多大的相关性?
