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

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

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

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

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


当前回答

如果一个普通的生产程序有10万行代码,每一行大约有8-12条汇编指令,那就是100万条汇编指令。

即使您可以以相当快的速度手写所有这些代码(请记住,这是您必须编写的8倍代码),如果您想更改某些功能会发生什么?从这100万条指令中理解你几周前写的东西简直是一场噩梦!没有模块,没有类,没有面向对象的设计,没有框架,什么都没有。即使是为最简单的事情编写的类似代码的数量最多也令人生畏。

此外,你不能像高级语言那样优化你的代码。例如,C语言执行了大量的优化,因为你描述了你的意图,不仅仅是你的代码,在汇编程序中你只写代码,汇编程序不能对你的代码执行任何值得注意的优化。你写的就是你得到的,相信我,你不可能可靠地优化100万条指令,你在写的时候不断地打补丁。

其他回答

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

因此,您基本上是在说,通过熟练地使用复杂的汇编程序,您可以使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语言的努力就比想出更好的东西的努力更大。

你好,我是一个编译器。

I just scanned thousands of lines of code while you were reading this sentence. I browsed through millions of possibilities of optimizing a single line of yours using hundreds of different optimization techniques based on a vast amount of academic research that you would spend years getting at. I won't feel any embarrassment, not even a slight ick, when I convert a three-line loop to thousands of instructions just to make it faster. I have no shame to go to great lengths of optimization or to do the dirtiest tricks. And if you don't want me to, maybe for a day or two, I'll behave and do it the way you like. I can transform the methods I'm using whenever you want, without even changing a single line of your code. I can even show you how your code would look in assembly, on different processor architectures and different operating systems and in different assembly conventions if you'd like. Yes, all in seconds. Because, you know, I can; and you know, you can't.

附言:哦,顺便说一下,你没有使用你写的一半代码。我帮了你一个忙,把它扔了。

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

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

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

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

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

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

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

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

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

其他人说的大多都是这样。

在C语言发明之前的美好时光里,当唯一的高级语言是像COBOL和FORTRAN这样的东西时,有很多事情不借助汇编程序是不可能完成的。这是获得全面灵活性的唯一方法,能够访问所有设备等等。但是后来C语言被发明了,在C语言中,几乎所有在汇编中可能实现的事情都可以实现。从那以后,我很少写汇编。

也就是说,我认为这是一个非常有用的练习,新程序员学习编写汇编程序。不是因为他们会经常使用它,而是因为这样你就能理解计算机内部到底发生了什么。我见过很多编程错误和低效的代码,它们来自程序员,他们显然不知道比特、字节和寄存器到底发生了什么。