为什么不经常在汇编中编写程序？

Question

似乎主流观点认为汇编编程需要更长时间并且比C等更高级别的语言更难编程.因此,似乎建议或假设出于这些原因更好地编写更高级别的语言并且为了更好的便携性.

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

也许是因为汇编程序设计与HLL完全不同,因此需要不同的思维,方法和方法,这使得为不熟悉的程序编程看起来很尴尬,因此给它编写程序的坏名称.

如果可移植性不是问题,那么真的,C会对NASM这样的好汇编程序有什么影响？

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

Answer 1

Hell®,我是编译器.

我在阅读这句话时只扫描了数千行代码.我根据您将花费数年时间学习的大量学术研究,使用数百种不同的优化技术浏览了数百种优化单行产品的可能性.当我将三行循环转换为数千条指令以使其更快时,我不会感到任何尴尬,甚至不是轻微的ick.我不遗余力地进行大量的优化或做最肮脏的技巧.如果你不想要我,也许一两天,我会按照你喜欢的方式行事.我可以随时转换我正在使用的方法,甚至不用改变代码的一行.我甚至可以向您展示您的代码在汇编,不同处理器架构和不同操作系统以及不同的汇编约定中的外观(如果您愿意).是的,几秒钟内完成.因为,你知道,我可以; 而且你知道,你做不到.

PS哦,顺便说一句,你没有使用你编写的一半代码.我帮了你一个忙,把它丢了.

Answer 2

与高级语言相比,ASM的易读性差,并且不能真正维护.

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

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

如果下一个CPU有两倍的寄存器怎么办？

与此问题相反的是:编译器提供了哪些功能？

我怀疑你能否/希望/应该优化你的ASM gcc -O3.

Answer 3

我已经为6502,Z80,6809和8086芯片编写了大量的汇编程序.一旦C编译器可用于我正在处理的平台,我就会停止这样做,并且立即变得至少提高了10倍.大多数优秀的程序员出于合理的原因使用他们使用的工具.

Answer 4

我喜欢使用汇编语言编程,但是需要更多的代码才能完成与高级语言相同的操作,并且代码行和错误之间存在直接关联.(几十年前在神话人月中解释过这一点.)

可以将C视为"高级装配",但要比上面几步更快,你就处于一个不同的世界.在C#中,你不要三思而后行:

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

这将是几十个,也许是数百行代码的汇编,每个程序员实现它将采取不同的方法,而下一个人出现将不得不弄明白.因此,如果您认为(尽可能多)程序主要是为其他人阅读而编写的,那么程序集的可读性就低于典型的HLL.

编辑:我积累了一个用于常见任务的个人代码库,以及用于实现类C控件结构的宏.但是当我成为常态时,我在90年代碰壁了.在常规事物上花费了太多时间.

几年前ASM必不可少的最后一项任务是编写代码来对抗恶意软件.没有用户界面,所以这是没有膨胀的所有有趣的部分.

Answer 5

除了其他人的可读性,可维护性,更短的代码,因此更少的错误,以及更容易的答案,我还将添加一个额外的原因:

程序速度.

是的,在汇编中,您可以手动调整代码以利用每个最后一个周期并使其尽可能快地完成.但谁有时间？如果你编写一个非完全愚蠢的C程序,编译器将很好地为你做优化.可能需要手动完成至少95%的优化,而不必担心跟踪其中的任何优化.这里肯定有一个90/10的规则,其中最后5%的优化将最终占用95%的时间.那为什么要这么麻烦？

Answer 6

如果一个平均生产程序说100k行代码,并且每行约8-12个汇编指令,那将是100万个汇编指令.

即使您可以以合适的速度手动编写所有这些(请记住,它的代码是您必须编写的8倍),如果您想要更改某些功能会发生什么？几个星期前你在这100万条指令中理解你所写的东西是一场噩梦!没有模块,没有类,没有面向对象的设计,没有框架,没有任何东西.即使是最简单的事情,您必须编写的类似外观代码的数量也是令人生畏的.

此外,您几乎不能像高级语言那样优化代码.例如,由于您描述了您的意图,而不仅是您的代码,而您只编写代码,因此汇编程序无法对您的代码执行任何值得注意的优化.你写的是你得到的,相信我,你不能可靠地优化你编写它时修补和修补的100万条指令.

Answer 7

好吧,我在"过去"写过很多集会,我可以向你保证,当我用高级语言编写程序时,我的工作效率会更高.

Answer 8

合理水平的汇编程序能力是一项非常有用的技能,特别是如果你在任何系统级别或嵌入式编程中工作,而不是因为你必须编写那么多的汇编程序,但是因为有时理解这个盒子真的在做什么很重要.如果您对汇编器概念和问题没有一个低级别的了解,那么这可能非常困难.

然而,至于在汇编程序中实际编写大量代码,有几个原因并没有做太多.

• 根本没有(几乎)需要.除了非常早期的系统初始化以及隐藏在C函数或宏中的一些汇编程序片段之外,所有可能曾经用汇编语言编写的非常低级的代码都可以用C或C++编写而没有任何困难.

• 高级语言(甚至C和C++)中的代码将功能集中到更少的行中,并且有大量研究表明错误的数量与源代码行数相关.也就是说,在汇编程序和C中解决的同样问题将在汇编程序中出现更多错误,因为它更长.同样的论点促使人们转向更高级别的语言,如Perl,Python等.

• 在汇编程序中编写,你必须处理问题的每个方面,从详细的内存布局,指令选择,算法选择,堆栈管理等.更高级别的语言将所有这些都从你身边带走,这就是为什么这么多密集的LOC条款.

从本质上讲,上述所有内容都与汇编程序与C或其他语言中可用的抽象级别有关.汇编程序强迫您完成所有自己的抽象,并通过自己的自律来维护它们,其中任何中级语言(如C语言,特别是高级语言)为您提供开箱即用的抽象,以及能够相对容易地创建新的.

Answer 9

在汇编时编写时,不必只是在指令代码中编写.您可以使用宏和过程以及您自己的约定来进行各种抽象,以使程序更加模块化,更易于维护和更易于阅读.

所以你基本上说的是,通过熟练使用复杂的汇编程序,你可以使你的ASM代码越来越接近C(或者你自己发明的另一种低级语言),直到最终你只是和C程序员一样高效.

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

我没有说这句话:我已经使用了这样的汇编程序和系统编程.更好的是,汇编程序可以定位虚拟处理器,并且单独的转换器为目标平台编译汇编程序的输出.与LLVM的IF一样,但在其早期形式中约会10年.因此具有可移植性,以及为特定目标合并器编写例程以满​​足效率的能力.

使用该汇编程序的编写与C一样高效,并且与GCC-3(在我参与的时候)相比,汇编程序/转换程序生成的代码大致同样快,通常更小.规模非常重要,该公司的程序员很少,并愿意在新员工做任何有用的事情之前教新员工.我们得到了备份,那些不了解汇编程序的人(例如客户)可以编写C并使用相同的调用约定等编译它来使用相同的虚拟处理器,以便它可以整齐地连接.所以这感觉就像是一场微不足道的胜利.

这就是开发汇编技术,库等等多年的工作.不可否认的是,如果它只是针对一个架构,那么其中大部分都是可移植的,那么全能的全能舞蹈汇编器就会容易得多.

总结:你可能不喜欢C,但这并不意味着使用C的努力大于提出更好的东西的努力.

Answer 10

作为一名花费大部分时间在嵌入式编程领域的开发人员,我认为汇编远非死亡/过时的语言.存在一定的接近金属级别的编码(例如,在驱动程序中),有时无法在更高级别的语言中准确或有效地表达.我们在汇编程序中编写了几乎所有的硬件接口例程.

话虽这么说,这个汇编代码被包装,以便它可以从C代码调用,并被视为库.出于多种原因,我们不会在程序集中编写整个程序.首要的是便携性; 我们的代码库用于使用不同体系结构的多个产品,我们希望最大化可以在它们之间共享的代码量.其次是开发人员熟悉.简而言之,学校不像过去那样教授装配,而且我们的开发人员在C方面的工作效率远远高于装配方式.此外,我们有可用于我们的C代码的各种"附加功能"(如库,调试器,静态分析工具等),这些代码不适用于汇编语言代码.即使我们想编写一个纯汇编程序,我们也无法编写,因为几个关键的硬件库只能用作C库.从某种意义上说,这是一个鸡/蛋问题.由于没有尽可能多的库和开发/调试工具,人们被驱逐出组装,但是libs/tools并不存在,因为没有足够的人使用程序集来保证创建它们的努力.

最后,几乎任何语言都有时间和地点.人们使用他们最熟悉和最富有成效的东西.在程序员的汇编程序中可能总会有一个位置,但是大多数程序员会发现他们可以用更高级别的语言编写代码,这种语言在很短的时间内几乎同样有效.

Answer 11

组装在不同的微处理器之间不可移植.

Answer 12

我们不再去外面的浴室,或者为什么我们不说拉丁语或亚拉姆语.

技术出现并使事情变得更容易和更容易获得.

编辑 - 为了停止犯罪的人,我删除了某些单词.