汇编编程比高级语言(如c)花费更长的时间,更难编程,这似乎是一种主流观点。因此,出于这些原因以及更好的可移植性,似乎建议或假设用高级语言编写更好。

最近我一直在用x86汇编语言写作,我开始意识到这些原因可能都不是真的,除了可移植性。也许这更多的是一个熟悉的问题,知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。

也许是因为汇编编程与hll有很大的不同,因此需要不同的思维、方法和方式,这使得对不熟悉的人编写程序看起来非常尴尬,因此给汇编编程带来了不好的名声。

如果可移植性不是问题,那么C语言比NASM这样的优秀汇编器有什么优势呢?

编辑: 我只是想指出。当你用汇编语言写作时,你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象,使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。


当前回答

C语言优于一个好的宏汇编器的地方是C语言类型检查。循环结构。自动栈管理。(几乎)自动变量管理。动态内存技术在汇编是一个巨大的痛苦在屁股。与C或更好的foo.insert()列表相比,正确地执行链表是非常可怕的。还有调试——嗯,谁更容易调试谁也不存在争议。他们在那儿轻而易举就赢了。

我几乎一半的职业生涯都是用汇编程序编写的,这让我很容易用汇编程序思考。它帮助我了解C编译器在做什么,这再次帮助我编写C编译器可以有效处理的代码。用C编写的一个经过深思熟虑的例程可以在汇编程序中输出你想要的东西——而且它是可移植的!由于跨平台的原因,我已经不得不将一些旧的asm例程重写回C,这并不有趣。

不,我将坚持使用C,并处理与使用HLL获得的生产时间相比偶尔出现的轻微性能放缓。

其他回答

我猜即使是x86(_64)上的ASM也有意义,因为您可以利用编译器难以优化的指令来获得很多好处。以X264为例,它使用了大量的asm编码,速度增益是巨大的。

因为事情总是这样:时间流逝,美好的东西也会消逝:(

但是当你编写asm代码时,这与编写高级语言的感觉完全不同,尽管你知道它的效率要低得多。这就像你是一个画家:你可以自由地画任何你喜欢的东西,完全没有限制(嗯,只有CPU的功能)……这就是我喜欢它的原因。很遗憾这种语言消失了。但只要有人还记得它并对它进行编码,它就永远不会消亡!

不同之处在于,汇编程序是一门代码的艺术,是一幅出自艺术家之手的好画。你比蹩脚的编译器代码聪明吗?如果你是,使用它或照顾你的绘画与c和汇编一起。

与高级语言相比,ASM的易读性很差,而且实际上难以维护。

此外,ASM开发人员比其他更流行的语言(如C)要少得多。

此外,如果您使用高级语言,并且有新的ASM指令可用(例如SSE),您只需要更新您的编译器,您的旧代码就可以轻松使用新的指令。

如果下一个CPU有两倍多的寄存器呢?

这个问题的反义词是:编译器提供了什么功能?

我怀疑你能够/想要/应该比gcc -O3更好地优化你的ASM。

浏览这些答案,我敢打赌9/10的回复者从未使用过组装。

这是一个经常出现的老问题,你得到的答案都是一样的,而且大多是错误的答案。如果不是为了便携性,我仍然会自己组装所有的东西。即便如此,我还是用C编写代码,就像用汇编一样。