合理水平的汇编能力是一项有用的技能，特别是当您从事任何类型的系统级或嵌入式编程时，这并不是因为您必须编写那么多汇编程序，而是因为有时了解盒子的实际功能非常重要。如果您对汇编程序的概念和问题没有低级的理解，这可能会非常困难。

然而，至于在汇编器中实际编写大量代码，有几个原因导致它做得不多。

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，特别是高级语言，都可以为您提供开箱即用的抽象，以及相对容易地创建新抽象的能力。

我喜欢用汇编语言编程，但是用高级语言做同样的事情需要更多的代码，而且代码行和错误之间有直接的联系。(这在几十年前的《人月神话》中就有解释。)

可以把C语言看作是“高级汇编”，但再往上走几步，你就进入了另一个世界。在c#中，你不需要三思就可以写这样的代码:

foreach (string s in listOfStrings) { /* do stuff */ }

这将是几十行，甚至几百行的汇编代码，每个实现它的程序员将采用不同的方法，下一个来的人将不得不找出它。因此，如果您相信(许多人都相信)程序主要是为其他人阅读而编写的，那么汇编的可读性就不如典型的HLL。

编辑:我积累了一个用于常见任务的个人代码库，以及用于实现类c控制结构的宏。但在90年代，当gui成为常态时，我遇到了瓶颈。太多的时间被花在了例行公事上。

我的上一个需要使用ASM的任务是在几年前，编写代码来对抗恶意软件。没有用户界面，所以只有有趣的部分，没有臃肿的部分。

可移植性始终是一个问题——如果不是现在，至少最终是这样。编程行业每年花费数十亿美元移植旧软件，这些软件在编写时“显然”没有任何可移植性问题。

正如其他人之前提到的，任何工具存在的原因都是它的工作效率。由于hll可以完成与许多行asm代码相同的工作，我想汇编被其他语言取代是很自然的。对于接近硬件的操作——有C语言的内联汇编和每种语言的其他变体。 保罗·卡特博士在PC汇编语言中说

＂...更好地理解如何 计算机实际上是在较低的水平上工作的 而不是编程语言 帕斯卡。通过获得更深层次的 了解计算机的工作原理， 读者通常可以做得更多 生产开发软件 高级语言，如C和 c++。学习汇编编程 语言是一种极好的方法 实现这个目标。”

在我的大学课程中有装配入门。这将有助于理清概念。然而，我怀疑我们中是否有人会用汇编编写90%的代码。今天深入的组装知识有多大的相关性?

人们似乎忘记了还有另一个方向。

为什么你一开始要用汇编语言写东西?为什么不用一种真正低级的语言来编写程序呢?

而不是

mov eax, 0x123
add eax, 0x456
push eax
call printInt

你还是写吧

B823010000
0556040000
50 
FF15.....

这有很多好处，你知道你的程序的确切大小，你可以重用指令的值作为其他指令的输入，你甚至不需要汇编程序来编写它，你可以使用任何文本编辑器……

你仍然喜欢汇编程序的原因，是其他人喜欢C语言的原因。

当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。

因此，您基本上是在说，通过熟练地使用复杂的汇编程序，您可以使ASM代码越来越接近C(或者您自己发明的另一种低级语言)，直到最终您的工作效率与C程序员一样高。

这是否回答了你的问题?: -)

我并不是在无所事事地说:我已经使用这样的汇编器和系统进行了编程。更好的是，汇编程序可以以虚拟处理器为目标，并且一个单独的翻译程序可以为目标平台编译汇编程序的输出。与LLVM的IF很相似，但其早期形式比它早了大约10年。因此，有了可移植性，再加上为特定目标汇编器编写例程的能力，以提高效率。

Writing using that assembler was about as productive as C, and with by comparison with GCC-3 (which was around by the time I was involved) the assembler/translator produced code that was roughly as fast and usually smaller. Size was really important, and the company had few programmers and was willing to teach new hires a new language before they could do anything useful. And we had the back-up that people who didn't know the assembler (e.g. customers) could write C and compile it for the same virtual processor, using the same calling convention and so on, so that it interfaced neatly. So it felt like a marginal win.

这是在开发汇编程序技术、库等方面花费了许多人多年的工作。不可否认的是，其中大部分都是为了使其可移植，如果它只针对一种架构，那么所有唱歌所有跳舞的汇编器就会容易得多。

总而言之:你可能不喜欢C语言，但这并不意味着使用C语言的努力就比想出更好的东西的努力更大。