汇编编程比高级语言(如c)花费更长的时间,更难编程,这似乎是一种主流观点。因此,出于这些原因以及更好的可移植性,似乎建议或假设用高级语言编写更好。
最近我一直在用x86汇编语言写作,我开始意识到这些原因可能都不是真的,除了可移植性。也许这更多的是一个熟悉的问题,知道如何写好汇编。我还注意到在汇编中编程与在HLL中编程有很大的不同。也许一个好的、有经验的汇编程序员可以像一个有经验的C程序员用C写程序一样轻松、快速地编写程序。
也许是因为汇编编程与hll有很大的不同,因此需要不同的思维、方法和方式,这使得对不熟悉的人编写程序看起来非常尴尬,因此给汇编编程带来了不好的名声。
如果可移植性不是问题,那么C语言比NASM这样的优秀汇编器有什么优势呢?
编辑:
我只是想指出。当你用汇编语言写作时,你不必只写指令代码。您可以使用宏、过程和您自己的约定来进行各种抽象,使程序更模块化、更可维护、更易于阅读。这就是熟悉如何编写好的汇编的原因。
合理水平的汇编能力是一项有用的技能,特别是当您从事任何类型的系统级或嵌入式编程时,这并不是因为您必须编写那么多汇编程序,而是因为有时了解盒子的实际功能非常重要。如果您对汇编程序的概念和问题没有低级的理解,这可能会非常困难。
然而,至于在汇编器中实际编写大量代码,有几个原因导致它做得不多。
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,特别是高级语言,都可以为您提供开箱即用的抽象,以及相对容易地创建新抽象的能力。
Oh hai, I'm a dataflow system. This App I'm running, are full of varrrious components. It's a distributed app, and it resides in 3 computers, on a powerful x86 and two smaller ARMs. Most of the components are written in C++, but there is a critical one written in ASM for the x86. Also, most components have several variations: compiled for different processors, also some components have special GPU versions. Shame or not, I have a script component (a wrapper component calls a script), which prints report, but only once a year. It doesn't even hurt that it's just a script, a slow script.
作为一个智能数据流应用程序,我知道,我的架构只适合特定的任务,其中信号/数据通过图形流动,例如自动化,视频/图像处理,音频处理(所有合成器使用数据流),但幸运的是,这些应用领域是非常需要功率的,其中优化是必不可少的。
我很确定有一天会出现一些其他的架构,它们也是关于优化(以及其他让编程更容易等的东西),它们将能够覆盖更多或其他领域,而我,数据流不能。
因此,“C vs ASM”的话题并不是一个真正的困境。这就像是在争论数字合成器还是模拟合成器更好(就像我之前提到的,我一直在研究合成器)。我建议,做好听的音乐。或倾听。无论什么。C不是相对于ASM。无论如何,我从未见过一个C程序被ASM攻击,反之亦然。
对不起,我的英语不好,尽管我不是一个新技术,我不是广为人知,我是一个孩子。很有希望。来,看看我的资料!
我用汇编编程已经有一个月了。我经常用C写一段代码,然后把它编译成汇编来帮助我。也许我没有充分利用C编译器的优化功能,但似乎我的C asm源包含不必要的操作。所以我开始看到,一个好的C编译器胜过一个好的汇编编码器的说法并不总是正确的。
Anyways, my assembly programs are so fast. And the more I use assembly the less time it takes me to write out my code because it's really not that hard. Also the comment about assembly having poor legibility is not true. If you label your programs correctly and make comments when there is additional elaboration needed you should be all set. In fact in ways assembly is more clear to the programmer because they are seeing what is happening at the level of the processor. I don't know about other programmers but for me I like knowing what's happening, rather than things being in a sort of black box.
With that said the real advantage of compilers is that a compiler can understand patterns and relationships and then automatically code them in the appropriate locations in the source. One popular example are virtual functions in C++ which requires the compiler to optimally map function pointers. However a compiler is limited to doing what the maker of the compiler allows the compiler to do. This leads to programmers sometimes having to resort to doing bizarre things with their code , adding coding time, when they could have been done trivially with assembly.
Personally I think the marketplace heavily supports high level languages. If assembly language was the only language in existence today then their would be about 70% less people programming and who knows where our world would be, probably back in the 90's. Higher level languages appeal to a broader range of people. This allows a higher supply of programmers to build the needed infrastructure of our world. Developing nations like China and India benefit heavily from languages like Java. These countries will fast develop their IT infrastructure and people will become more interconnected. So my point is that high level languages are popular not because they produce superior code but because they help to meet demand in the world's marketplaces.