汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
C语言优于一个好的宏汇编器的地方是C语言类型检查。循环结构。自动栈管理。(几乎)自动变量管理。动态内存技术在汇编是一个巨大的痛苦在屁股。与C或更好的foo.insert()列表相比，正确地执行链表是非常可怕的。还有调试——嗯，谁更容易调试谁也不存在争议。他们在那儿轻而易举就赢了。
我几乎一半的职业生涯都是用汇编程序编写的，这让我很容易用汇编程序思考。它帮助我了解C编译器在做什么，这再次帮助我编写C编译器可以有效处理的代码。用C编写的一个经过深思熟虑的例程可以在汇编程序中输出你想要的东西——而且它是可移植的!由于跨平台的原因，我已经不得不将一些旧的asm例程重写回C，这并不有趣。
不，我将坚持使用C，并处理与使用HLL获得的生产时间相比偶尔出现的轻微性能放缓。
其他回答
合理水平的汇编能力是一项有用的技能，特别是当您从事任何类型的系统级或嵌入式编程时，这并不是因为您必须编写那么多汇编程序，而是因为有时了解盒子的实际功能非常重要。如果您对汇编程序的概念和问题没有低级的理解，这可能会非常困难。
然而，至于在汇编器中实际编写大量代码，有几个原因导致它做得不多。
There's simply no (almost) need. Except for something like the very early system initialization and perhaps a few assembler fragments hidden in C functions or macros, all very low-level code that might once have been written in assembler can be written in C or C++ with no difficulty. Code in higher-level languages (even C and C++) condenses functionality into far fewer lines, and there is considerable research showing that the number of bugs correlates with the number of lines of source code. Ie, the same problem, solved in assembler and C, will have more bugs in assembler simply because its longer. The same argument motivates the move to higher level languages such as Perl, Python, etc. Writing in assembler, you have to deal with every single aspect of the problem, from detailed memory layout, instruction selection, algorithm choices, stack management, etc. Higher level languages take all this away from you, which is why are so much denser in terms of LOC.
从本质上讲，以上所有内容都与汇编程序与C或其他语言中可用的抽象级别有关。汇编程序迫使您自己制作所有的抽象，并通过您自己的自律来维护它们，而任何中级语言，如C，特别是高级语言，都可以为您提供开箱即用的抽象，以及相对容易地创建新抽象的能力。
因为事情总是这样:时间流逝，美好的东西也会消逝:(
但是当你编写asm代码时，这与编写高级语言的感觉完全不同，尽管你知道它的效率要低得多。这就像你是一个画家:你可以自由地画任何你喜欢的东西，完全没有限制(嗯，只有CPU的功能)……这就是我喜欢它的原因。很遗憾这种语言消失了。但只要有人还记得它并对它进行编码，它就永远不会消亡!
其他人说的大多都是这样。
在C语言发明之前的美好时光里，当唯一的高级语言是像COBOL和FORTRAN这样的东西时，有很多事情不借助汇编程序是不可能完成的。这是获得全面灵活性的唯一方法，能够访问所有设备等等。但是后来C语言被发明了，在C语言中，几乎所有在汇编中可能实现的事情都可以实现。从那以后，我很少写汇编。
也就是说，我认为这是一个非常有用的练习，新程序员学习编写汇编程序。不是因为他们会经常使用它，而是因为这样你就能理解计算机内部到底发生了什么。我见过很多编程错误和低效的代码，它们来自程序员，他们显然不知道比特、字节和寄存器到底发生了什么。
不同之处在于，汇编程序是一门代码的艺术，是一幅出自艺术家之手的好画。你比蹩脚的编译器代码聪明吗?如果你是，使用它或照顾你的绘画与c和汇编一起。
C语言优于一个好的宏汇编器的地方是C语言类型检查。循环结构。自动栈管理。(几乎)自动变量管理。动态内存技术在汇编是一个巨大的痛苦在屁股。与C或更好的foo.insert()列表相比，正确地执行链表是非常可怕的。还有调试——嗯，谁更容易调试谁也不存在争议。他们在那儿轻而易举就赢了。
我几乎一半的职业生涯都是用汇编程序编写的，这让我很容易用汇编程序思考。它帮助我了解C编译器在做什么，这再次帮助我编写C编译器可以有效处理的代码。用C编写的一个经过深思熟虑的例程可以在汇编程序中输出你想要的东西——而且它是可移植的!由于跨平台的原因，我已经不得不将一些旧的asm例程重写回C，这并不有趣。
不，我将坚持使用C，并处理与使用HLL获得的生产时间相比偶尔出现的轻微性能放缓。
