汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
C是一个宏汇编器!这是最好的一个!
它可以做几乎所有汇编程序可以做的事情，它是可移植的，在大多数极少数情况下，当它不能做一些事情时，你仍然可以使用嵌入式汇编代码。这就只留下了一小部分程序，你绝对需要用汇编来编写，而且只需要汇编。
更高层次的抽象和可移植性使大多数人更值得用c语言编写系统软件。尽管你现在可能不需要可移植性，但如果你在编写某个程序上投入了大量的时间和金钱，你可能不想把自己限制在将来可以使用它的地方。
其他回答
早期的发现之一(你可以在布鲁克斯的《神秘的人月》中找到，这是20世纪60年代的经验)是，人们使用一种语言的效率或多或少与使用另一种语言的效率一样高，每天调试的代码行数也差不多。显然，这并不是普遍的事实，如果做得太过分，可能会崩溃，但对于Brooks时代的高级语言来说，这是普遍的事实。
因此，提高工作效率的最快方法是使用一行代码就能做更多工作的语言，这确实有效，至少对于像FORTRAN和COBOL这样复杂的语言，或者给出一个更现代的例子C。
我相信有很多原因，但我能想到的两个原因是
汇编代码肯定更难读(我肯定编写它也更耗时) 当您有一个庞大的开发团队在开发一个产品时，将代码划分为逻辑块并通过接口进行保护是很有帮助的。
C语言优于一个好的宏汇编器的地方是C语言类型检查。循环结构。自动栈管理。(几乎)自动变量管理。动态内存技术在汇编是一个巨大的痛苦在屁股。与C或更好的foo.insert()列表相比，正确地执行链表是非常可怕的。还有调试——嗯，谁更容易调试谁也不存在争议。他们在那儿轻而易举就赢了。
我几乎一半的职业生涯都是用汇编程序编写的，这让我很容易用汇编程序思考。它帮助我了解C编译器在做什么，这再次帮助我编写C编译器可以有效处理的代码。用C编写的一个经过深思熟虑的例程可以在汇编程序中输出你想要的东西——而且它是可移植的!由于跨平台的原因，我已经不得不将一些旧的asm例程重写回C，这并不有趣。
不，我将坚持使用C，并处理与使用HLL获得的生产时间相比偶尔出现的轻微性能放缓。
随着汇编变得越来越不常见，出现了一个恶性循环:随着高级语言的成熟，汇编语言指令集的构建越来越少地是为了方便程序员，而更多地是为了方便编译器。
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#.
如果您的问题很容易用高效的汇编语言来表达，那么您的能力就更强了。
你好，我是一个编译器。
I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.
附言:哦，顺便说一下，你没有使用你写的一半代码。我帮了你一个忙，把它扔了。
