为什么程序不是更经常用Assembly编写的？[关闭]

主流的观点似乎是：汇编语言比诸如C的高级语言花费的时间更长，并且编程起来更困难。因此，出于这些原因，似乎建议或假定最好使用高级语言编写并且出于更好的可移植性。

最近，我一直在写x86汇编语言，这使我意识到，也许这些原因并不是真的，除了可移植性。也许更多的是熟悉和知道如何编写汇编。我还注意到，汇编语言编程与HLL编程完全不同。也许一个优秀且经验丰富的汇编程序员可以像使用C语言编写经验丰富的C程序员一样轻松快捷地编写程序。

也许是因为汇编编程与HLL完全不同，并且需要不同的思维，方法和方式，这使得对于不熟悉的编程变得很尴尬，因此给它起了不好的名字来编写程序。

如果可移植性不是问题，那么，对于像NASM这样的优秀汇编程序，C真的有什么呢？

编辑： 只是指出。当您使用汇编语言编写时，您不必只编写指令代码。您可以使用宏和过程以及您自己的约定来进行各种抽象，以使程序更具模块化，更可维护且更易于阅读。这是熟悉如何编写良好汇编的地方。

与高级语言相比，ASM的可读性较差，并且实际上不可维护。

而且，与其他更流行的语言（例如C）相比，ASM开发人员要少得多。

此外，如果您使用高级语言并且有新的ASM指令可用（例如SSE），则只需更新编译器，您的旧代码即可轻松使用新指令。

如果下一个CPU的寄存器数量增加一倍该怎么办？

这个问题的反面是：编译器提供什么功能？

我怀疑您能否/希望/应该比自己更好地优化ASM gcc -O3。

该死，我是编译器。

当您阅读此句子时，我刚刚扫描了数千行代码。我浏览了数百万种可能的方法，这些方法是基于数百种您将花费数年才能完成的学术研究，使用数百种不同的优化技术来优化您的单行的。当我将三行循环转换为成千上万条指令以使其更快时，我不会感到任何尴尬，甚至一点点都不会。我不羞耻地进行了大量的优化工作或进行最肮脏的技巧。如果您不希望我这样做，也许是一两天，我就会表现出来并按照您喜欢的方式进行。我可以随时更改我正在使用的方法，甚至无需更改代码的任何一行。我什至可以向您展示代码在汇编中的外观，如果您愿意，可以在不同的处理器体系结构，不同的操作系统以及不同的组装约定上使用。是的，只需几秒钟。因为，你知道，我可以；而且你知道，你做不到。

PS哦，顺便说一下，您没有使用所编写代码的一半。我帮了你一个忙，把它扔了。

我已经为6502，Z80、6809和8086芯片编写了大量汇编程序。一旦C编译器可用于我要处理的平台，我便停止这样做，并立即提高了至少10倍的生产率。大多数优秀的程序员出于理性原因都使用他们使用的工具。

我喜欢使用汇编语言进行编程，但是要完成与高级语言相同的工作，需要花费更多的代码，并且代码行和错误之间存在直接的关联。（这在几十年前的《神话人月》中进行了解释。）

可以将C视为“高级程序集”，但在此基础上走了几步，您就进入了另一个世界。在C＃中，您无需三思而后行：

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

这将是数十行，甚至数百行代码的汇编，每个实现它的程序员都将采用不同的方法，而下一个人将不得不弄清楚它。因此，如果您相信（就像许多人一样）程序主要是供其他人阅读的，则汇编程序比典型的HLL可读性差。

编辑：我积累了用于日常任务的个人代码库，以及用于实现类似C的控制结构的宏。但是在90年代，当GUI成为标准时，我碰壁了。在例行事务上花了太多时间。

我对ASM至关重要的最后一项任务是几年前，编写代码来对抗恶意软件。没有用户界面，因此所有这些都很有趣，而且没有膨胀。

除了其他人对可读性，可维护性，较短的代码（从而减少错误）并且更容易实现的答案之外，我还要添加一个其他原因：

程序速度。

是的，在汇编中，您可以手动调整代码以利用每个上一个周期，并使其在物理上尽可能快。但是谁有时间？如果您编写的不是完全愚蠢的C程序，则编译器将为您做一个非常好的优化工作。大概可以手动完成至少95％的优化，而不必担心跟踪任何优化。这里肯定有90/10的规则，其中最后5％的优化最终将占用您95％的时间。那为什么要打扰呢？

如果一个普通的生产程序有10万行代码，而每一行大约是8到12条汇编程序指令，那将是一百万条汇编程序指令。

即使您可以以适当的速度手工编写所有这些内容（请记住，它是编写代码的8倍），但是如果您想更改某些功能会怎样？从几百万条指令中了解几周前您写的内容真是一场噩梦！没有模块，没有类，没有面向对象的设计，没有框架，什么都没有。即使是最简单的事情，您必须编写的看起来相似的代码充其量也令人望而生畏。

此外，您无法像高级语言一样优化您的代码。例如，在C语言中执行疯狂的优化是因为您描述了自己的意图，不仅是代码，在汇编器中您仅编写代码，而汇编器实际上无法对代码执行任何值得注意的优化。您所写的就是所得到的，并且请相信我，您无法可靠地优化在编写时修补和修补的100万条指令。

好吧，“过去”我一直在写很多程序集，并且可以向您保证，当我用高级语言编写程序时，我的工作效率更高。

汇编能力的合理水平是一个有用的技能，特别是如果你在任何类型的系统级或嵌入式编程工作，与其说是因为你写那么多汇编，而是因为有时要明白什么是框是很重要的真的做。如果您对汇编器的概念和问题不了解，那么可能会很难。

但是，至于实际上在汇编器中编写了很多代码，有很多原因导致它做得不好。

• 根本没有（几乎）需要。除了像早期的系统初始化之类的东西以及隐藏在C函数或宏中的一些汇编器片段外，所有曾经曾经用汇编器编写的非常低级的代码都可以毫不费力地用C或C ++编写。

• 用高级语言（甚至C和C ++）编写的代码将功能浓缩到少得多的行中，并且有大量研究表明，错误的数量与源代码的数量相关。即，在汇编器和C中解决的同一问题，仅是因为其较长，就会在汇编器中出现更多错误。相同的论点促使人们转向高级语言，例如Perl，Python等。

• 用汇编器编写时，您必须处理问题的各个方面，从详细的内存布局，指令选择，算法选择，堆栈管理等开始。高级语言使您无法使用所有这些，这就是为什么它们如此密集的原因LOC条款。

本质上，以上所有内容都与汇编程序对比C或其他某种语言所提供的抽象级别有关。汇编程序迫使您创建自己的所有抽象，并通过自己的自律来维护它们，在这种情况下，任何中级语言（例如C），尤其是高级语言，都可以为您提供现成的抽象，以及相对容易地创建新功能的能力。

作为一个将大部分时间都花在嵌入式编程世界上的开发人员，我认为汇编语言远非一成不变的语言。存在某些接近金属的编码级别（例如，在驱动程序中），有时无法用高级语言准确或有效地表示。我们几乎用汇编器编写所有的硬件接口例程。

话虽如此，该汇编代码被包装起来，以便可以从C代码中调用它，并将其视为库。由于种种原因，我们没有在汇编中编写整个程序。首先是可移植性；我们的代码库在使用不同体系结构的几种产品上使用，我们希望最大化它们之间可以共享的代码量。其次是开发人员的熟悉程度。简而言之，学校没有像过去那样教授汇编语言，而且我们的开发人员在C语言方面的效率远高于汇编语言。另外，我们有很多“附加”（例如库，调试器，静态分析工具等）可用于我们的C代码，而汇编语言代码则不可用。即使我们想编写一个纯汇编程序，我们将无法执行，因为几个关键的硬件库仅作为C库提供。从某种意义上说，这是鸡/蛋的问题。人们被迫离开汇编语言，因为没有太多可用的库和开发/调试工具，但是库/工具不存在，因为没有足够的人使用汇编语言来保证创建汇编语言的努力。

最后，几乎所有语言都有时间和地点。人们使用他们最熟悉和最有生产力的东西。在程序员的汇编库中可能总会有一个地方，但是大多数程序员会发现，他们可以用高级语言编写代码，而这种语言几乎可以用更少的时间获得相同的效率。

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

因此，您基本上要说的是，通过熟练地使用复杂的汇编器，可以使ASM代码越来越接近C（或者无论如何是您自己发明的另一种低端语言），直到最终您只是和C程序员一样有生产力。

这是否回答你的问题？;-)

我并不是说这个闲话：我已经使用这样的汇编器和系统进行了编程。更好的是，汇编程序可以将目标定为虚拟处理器，然后一个单独的转换器为目标平台编译汇编程序的输出。LLVM的IF发生了很多事情，但是它的早期形式要早10年左右。因此，它具有可移植性，以及为提高效率而为特定目标组装商编写例程的能力。

使用该汇编器编写代码的效率与C差不多，并且与GCC-3（在我参与此过程时差不多）进行比较，汇编器/翻译器产生的代码大致一样快，通常较小。规模真的很重要，公司几乎没有程序员，并且愿意在新员工做任何有用的事情之前教他们新的语言。我们有一个备份，那些不了解汇编程序的人（例如客户）可以编写C并使用相同的调用约定等在同一个虚拟处理器中对其进行编译，从而使C进行整齐的接口。因此，这感觉像是一场微弱的胜利。

那是在开发组装技术，库等方面花费了多年的精力。不可否认的是，其中很多都用于使其具有可移植性，如果它只是针对一种体系结构，那么全力以赴的全舞蹈汇编程序会容易得多。

总结：您可能不喜欢C，但这并不意味着使用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();
        }

与

.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转换为本机代码（即几乎是汇编程序），使其更加难以理解。

我想即使在x86（_64）上使用ASM在通过利用编译器难以优化的指令获得大量收益的情况下也是有意义的。例如，x264使用大量的asm进行编码，因此速度提升非常明显。

我敢肯定有很多原因，但是我能想到的两个快速原因是

1. 汇编代码肯定更难阅读（我很肯定它也更耗时）
2. 当您拥有庞大的产品开发团队时，将代码分成逻辑块并由接口保护会很有帮助。

早期发现之一（您会在Brooks的Mythical Man-Month中找到它，它是从1960年代的经验中得出的），人们每天在经过调试的代码行中使用一种语言的效率与另一种语言差不多。这显然不是普遍适用的，并且如果推得太远可能会中断，但这在布鲁克斯时代的高级语言中通常是适用的。

因此，提高生产率的最快方法是使用一种语言，其中一行代码可以完成更多工作，并且至少对于FORTRAN和COBOL之类的复杂语言，这确实有效，或者给出一个更现代的示例C。

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

随着汇编变得越来越不普遍，出现了一个恶性循环：随着高级语言的成熟，汇编语言指令集的构建为程序员带来的便利越来越少，而为编译器带来的便利却越来越多。

因此，实际上，现在可能很难做出正确的决定，例如，应该使用哪些寄存器或哪些指令效率更高。编译器可以使用启发式方法找出哪些折衷方案可能会获得最佳收益。我们可能可以考虑一些较小的问题，找到可以胜过我们现在非常复杂的编译器的局部优化，但是奇怪的是，在一般情况下，一个好的编译器比起一个好的程序员，在第一次尝试时会做得更好。最终，像约翰·亨利一样，我们可能会击败机器，但可能会严重烧伤自己。

现在我们的问题也大不相同。1986年，我试图弄清楚如何从涉及在屏幕上放置几百个像素的小程序中获得更高的速度。我希望动画不那么生涩。汇编语言的合理案例。现在，我正在尝试弄清如何表示有关抵押贷款的合同语言和服务商政策的抽象概念，而我希望阅读一些类似于商务人士所讲语言的东西。与LISP宏不同，汇编宏不会以规则的方式强制执行很多操作，因此，即使您可以在良好的汇编程序中获得与DSL相当接近的东西，也很容易发生各种奇怪的事情。如果我用Ruby，Boo，Lisp，C＃甚至F＃编写相同的代码，不会给我带来麻烦。

但是，如果您的问题很容易用高效的汇编语言表达，那么您将获得更大的权力。

同上大多数人所说的话。

在C发明之前的美好时光中，当唯一的高级语言是诸如COBOL和FORTRAN之类的东西时，有很多事情如果不依靠汇编器是不可能完成的。这是获得全部灵活性，能够访问所有设备等的唯一方法。但是后来发明了C，几乎所有在汇编中可能的事情都可以用C进行。然后。

就是说，对于新程序员来说，学习汇编语言编写是非常有用的练习。不是因为他们实际上会大量使用它，而是因为您随后了解了计算机内部真正发生的情况。我从程序员那里看到了许多编程错误和低效率的代码，这些程序员显然不知道位，字节和寄存器到底发生了什么。

我已经在汇编中编程了大约一个月。我经常用C语言编写一段代码，然后将其编译为汇编程序以帮助我。也许我没有利用C编译器的全部优化功能，但看来我的C asm源中包括不必要的操作。因此，我开始看到关于好的C编译器胜过好的汇编编码器的说法并不总是正确的。

无论如何，我的汇编程序是如此之快。而且我使用汇编的次数越多，编写代码所花费的时间就越少，因为这并不难。同样，关于汇编的可读性差的评论也不正确。如果您正确地标记了程序并在需要其他详细说明时发表评论，那么您应该准备就绪。实际上，对于程序员而言，汇编的方式更加清晰，因为他们可以看到处理器级别上正在发生的事情。我不了解其他程序员，但对我来说，我更喜欢知道正在发生的事情，而不是把事情弄成黑匣子。

这样说来，编译器的真正优势在于，编译器可以理解模式和关系，然后在源代码的适当位置自动对其进行编码。一个流行的例子是C ++中的虚函数，它要求编译器以最佳方式映射函数指针。但是，编译器只能进行编译器制造商允许编译器执行的操作。这导致程序员有时不得不诉诸于用代码做一些奇怪的事情，增加编码时间，而这本来可以用汇编来完成的。

我个人认为市场在很大程度上支持高级语言。如果汇编语言是当今唯一存在的语言，那么他们的编程人员和知道我们的世界的人将减少大约70％，大概是90年代。高级语言吸引了更广泛的人群。这允许更多的程序员来构建我们这个世界所需的基础架构。像中国和印度这样的发展中国家从Java等语言中受益匪浅。这些国家将快速发展其IT基础架构，人们之间的联系将会更加紧密。因此，我的观点是，高级语言之所以流行，不是因为它们产生了出色的代码，而是因为它们有助于满足世界市场的需求。

我现在正在comp org中学习汇编，虽然很有趣，但是编写效率也很低。您必须在头脑中保留更多细节才能使工作正常进行，并且编写相同事物的速度也较慢。例如，在C ++中，简单的6行for循环可以等于18行或更多行的汇编。

就个人而言，学习硬件在硬件上如何工作是一件很有趣的事，它使我对计算的工作方式有了更大的了解。

C语言比C语言具有更好的宏汇编器。类型检查。循环构造。自动堆栈管理。（几乎）自动变量管理。汇编程序中的动态内存技术是一个巨大的难题。与C或更好的列表foo.insert（）相比，正确地创建链接列表只是令人恐惧。和调试-好吧，在什么方面更容易调试没有竞争。HLL在那赢得胜利。

我已经将近一半的职业生涯用汇编语言编写，这使我很容易想到装配工。它可以帮助我了解C编译器在做什么，这又可以帮助我编写C编译器可以有效处理的代码。经过深思熟虑的用C编写的例程可以编写出来，只需花费很少的工作即可输出所需的汇编程序，而且它是可移植的！由于跨平台的原因，我已经不得不将一些较旧的asm例程改写回C，这很有趣。

不，我会坚持使用C并处理偶尔出现的性能下降（相对于HLL获得的生产力时间）。

我只能回答为什么我个人不经常在汇编中编写程序，而主要原因是这样做比较繁琐。另外，我认为在不立即注意到的情况下更容易发现错误。例如，您可能会在一个例程中更改使用寄存器的方式，但是忘记在一处更改它。它会很好地组装，您可能要等到很久以后才能注意到。

就是说，我确实认为汇编仍然有有效的用途。例如，我使用SIMD并遵循偏执的“每一位都是神圣的” [quote V.Stob]方法，有许多用于处理大量数据的相当优化的汇编例程。（但是请注意，幼稚的程序集实现通常比编译器为您生成的实现要差得多。）

C是宏汇编程序！这是最好的之一！

它几乎可以完成所有汇编程序，可以移植，并且在大多数罕见的情况下，它不能执行某些操作，您仍然可以使用嵌入式汇编代码。这样只剩下一小部分您绝对需要用汇编语言编写的程序，而无非是汇编语言。

而且更高层次的抽象性和可移植性使大多数人都可以用C编写系统软件。尽管现在如果您花费大量时间和金钱来编写某些程序，则可能不需要可移植性，但是您可能不想限制自己将来您将可以使用它。

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

您为什么首先要在Assembler中写作？为什么不使用真正的低级语言编写程序？

代替

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

你也可以写

B823010000
0556040000
50 
FF15.....

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

您仍然偏爱汇编程序的原因是其他人偏爱C ...

因为总是这样：时间消逝，美好的事物也消逝:(

但是，当您编写asm代码时，与编写高级lang时的感觉完全不同，尽管您知道它的生产效率要低得多。就像您是画家一样：您可以自由地以自己喜欢的方式绘画任何东西，而没有任何限制（嗯，仅受CPU功能限制）...这就是为什么我喜欢它。可惜的是这种语言消失了。但是，尽管有人仍然记得它并对其进行编码，但它永远不会死！

$$$

一家公司雇用开发人员来帮助将代码转换为$$$。更快的是有用的代码可以产生，更快的公司可以把该代码转换成$$$。

更高级别的语言通常更适合于生产大量有用的代码。这并不是说大会没有它的位置，因为在某些时候和地方，别无他法。

当您将程序集与比C更高级的语言进行比较时，例如Java或Python或Ruby，HLL的优势甚至更大。例如，这些语言具有垃圾回收功能：无需担心何时释放一块内存，也不必担心由于过早释放而导致的内存泄漏或错误。

如前所述，任何工具存在的原因是它的工作效率。由于HLL可以完成与许多行asm代码相同的工作，我想很自然地可以将汇编语言替换为其他语言。并且对于接近硬件的摆弄-使用C语言进行内联汇编，以及根据语言的其他变体。Paul Carter博士用PC汇编语言说

“ ...比Pascal等编程语言更好地了解计算机的工作原理。通过对计算机如何工作有更深入的了解，读者通常可以使用C等高级语言开发软件，从而提高生产力。和C ++。学习使用汇编语言进行编程是实现此目标的绝佳方法。”

我们在大学课程中对组装进行了介绍。这将有助于清除概念。但是我怀疑我们中的任何人都将在汇编中编写90％的代码。今天，深入的装配知识有多重要？

翻阅这些答案，我敢打赌9/10的响应者从未使用过汇编程序。

这是一个古老的问题，每隔一段时间就会出现一次，您会得到相同的答案，大多数都是错误的答案。如果不是为了可移植性，我仍然会自己组装所有东西。即使那样，我也几乎像在汇编中那样用C编写代码。