汇编编程比高级语言(如c)花费更长的时间，更难编程，这似乎是一种主流观点。因此，出于这些原因以及更好的可移植性，似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作，我开始意识到这些原因可能都不是真的，除了可移植性。也许这更多的是一个熟悉的问题，知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同，因此需要不同的思维、方法和方式，这使得对不熟悉的人编写程序看起来非常尴尬，因此给汇编编程带来了不好的名声。
如果可移植性不是问题，那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑: 我只是想指出。当你用汇编语言写作时，你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象，使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
当前回答
人们似乎忘记了还有另一个方向。
为什么你一开始要用汇编语言写东西?为什么不用一种真正低级的语言来编写程序呢?
而不是
mov eax, 0x123
add eax, 0x456
push eax
call printInt
你还是写吧
B823010000
0556040000
50
FF15.....
这有很多好处，你知道你的程序的确切大小，你可以重用指令的值作为其他指令的输入，你甚至不需要汇编程序来编写它，你可以使用任何文本编辑器……
你仍然喜欢汇编程序的原因，是其他人喜欢C语言的原因。
其他回答
为什么?简单。
比较一下:
for (var i = 1; i <= 100; i++)
{
if (i % 3 == 0)
Console.Write("Fizz");
if (i % 5 == 0)
Console.Write("Buzz");
if (i % 3 != 0 && i % 5 != 0)
Console.Write(i);
Console.WriteLine();
}
with
.locals init (
[0] int32 i)
L_0000: ldc.i4.1
L_0001: stloc.0
L_0002: br.s L_003b
L_0004: ldloc.0
L_0005: ldc.i4.3
L_0006: rem
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0
L_0014: ldc.i4.5
L_0015: rem
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0
L_0023: ldc.i4.3
L_0024: rem
L_0025: brfalse.s L_0032
L_0027: ldloc.0
L_0028: ldc.i4.5
L_0029: rem
L_002a: brfalse.s L_0032
L_002c: ldloc.0
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0
L_0038: ldc.i4.1
L_0039: add
L_003a: stloc.0
L_003b: ldloc.0
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret
它们在功能上是相同的。 第二个甚至不是汇编程序，而是。net IL(中间语言，类似于Java的字节码)。第二次编译将IL转换为本地代码(即几乎是汇编程序)，使其更加神秘。
我现在正在comp组织学习汇编，虽然它很有趣，但它也非常低效。你必须在脑子里记住更多的细节才能让事情顺利进行，而且写同样的东西也会慢一些。例如，c++中一个简单的6行For循环可以等于18行或更多的汇编。
就我个人而言，学习硬件层面的工作方式非常有趣，它让我对计算的工作方式有了更多的了解。
与高级语言相比，ASM的易读性很差，而且实际上难以维护。
此外，ASM开发人员比其他更流行的语言(如C)要少得多。
此外，如果您使用高级语言，并且有新的ASM指令可用(例如SSE)，您只需要更新您的编译器，您的旧代码就可以轻松使用新的指令。
如果下一个CPU有两倍多的寄存器呢?
这个问题的反义词是:编译器提供了什么功能?
我怀疑你能够/想要/应该比gcc -O3更好地优化你的ASM。
如果一个普通的生产程序有10万行代码，每一行大约有8-12条汇编指令，那就是100万条汇编指令。
即使您可以以相当快的速度手写所有这些代码(请记住，这是您必须编写的8倍代码)，如果您想更改某些功能会发生什么?从这100万条指令中理解你几周前写的东西简直是一场噩梦!没有模块，没有类，没有面向对象的设计，没有框架，什么都没有。即使是为最简单的事情编写的类似代码的数量最多也令人生畏。
此外，你不能像高级语言那样优化你的代码。例如，C语言执行了大量的优化，因为你描述了你的意图，不仅仅是你的代码，在汇编程序中你只写代码，汇编程序不能对你的代码执行任何值得注意的优化。你写的就是你得到的，相信我，你不可能可靠地优化100万条指令，你在写的时候不断地打补丁。
早期的发现之一(你可以在布鲁克斯的《神秘的人月》中找到，这是20世纪60年代的经验)是，人们使用一种语言的效率或多或少与使用另一种语言的效率一样高，每天调试的代码行数也差不多。显然，这并不是普遍的事实，如果做得太过分，可能会崩溃，但对于Brooks时代的高级语言来说，这是普遍的事实。
因此，提高工作效率的最快方法是使用一行代码就能做更多工作的语言，这确实有效，至少对于像FORTRAN和COBOL这样复杂的语言，或者给出一个更现代的例子C。
