我目前正在研究电信和电子领域的工程学,我们已经从微处理器编程的汇编程序迁移到了C语言。我怀疑这是个好主意。与汇编相比,C有哪些优缺点?
我看到的优点/缺点是:
优点:
- 我可以说C语法比汇编器语法更容易学习。
- 使用C可以更轻松地制作更复杂的程序。
- 学习C比学习汇编器更有效率,因为围绕C的开发工作比汇编器要多。
缺点:
- 汇编器是比C更底层的编程语言,因此它非常适合直接对硬件进行编程。
- 暗示您可以使用内存,中断,微寄存器等的灵活性更高。
我目前正在研究电信和电子领域的工程学,我们已经从微处理器编程的汇编程序迁移到了C语言。我怀疑这是个好主意。与汇编相比,C有哪些优缺点?
我看到的优点/缺点是:
优点:
缺点:
Answers:
以下是一些可能对您有所帮助的堆栈溢出答案(这些是响应最高的,可接受的答案):
优点
/programming/143561/is-there-a-need-to-use-assembly-these-days(仅适用于1万用户)或存档
缺点
/programming/2684364/why-arent-programs-write-in-assembly-more-often
例
下面的最后一篇文章是Stack Overflow文章,概述了一个场景,该场景将显示比C更快的汇编示例(执行相同功能时)。
与汇编语言相比,C语言更易于编程。有明显的原因不值得重新哈希处理。
C易于使用,可让您更快地编写程序。通常,这些程序也更易于调试和维护。此外,使用C来管理大型复杂程序更加容易。
通常,由编译器生成的代码(在速度和效率方面)与手写汇编器一样好-如果不是更好。
C是低级的,很少有人会想降低C。增加抽象层很少是一件坏事。
当需要降低时,可以使用Assembly,否则可以使用C。
您可以用C代码编写Assembly,但是不能用C代码编写C。
在微处理器编程中,我们已从汇编程序迁移到C语言。我怀疑这是个好主意
不用担心,没有人再使用100%汇编程序开发新程序。如今,C甚至可以用于最微小,最糟糕的8位体系结构。但是,了解一些汇编程序会使您成为更好的C程序员。另外,程序中总是有一些小细节需要用汇编器编写。
我可以说C语法比汇编器语法更容易学习。
是的,语法肯定更容易。但是,学习整个C语言以及所有令人讨厌的细节比学习特定汇编程序的所有细节要复杂得多。C是一门更大更广泛的语言。但是话又说回来,您可能不需要学习所有细节。
使用C可以更轻松地制作更复杂的程序。
实际上,C提供了用于模块化程序设计的机制,例如封装和局部作用域/局部变量。C具有一个标准库,以及过去30年中编写的大量资源。最重要的是,C是可移植的。
学习C比学习汇编器更有效率,因为围绕C的开发工作比汇编器要多。
C具有大量的预制功能,库和资源,因此可以减少对轮子的重新发明。但除此之外,您的陈述是主观的。我相信这是个人喜好问题。
例如,我是一位经验丰富的C程序员,偶尔会编程C ++。我发现自己在C ++中的生产力远不如在C ++中高,因为我不了解C语言。但是仅仅因为我有这种感觉,并不一定意味着C语言中的编程比C ++中的编程更具生产力。有经验的C ++程序员肯定会有相反的看法。
“生产性”有很多方面。一个非常重要的方面是维护时间,尤其是修复由维护引起的错误所需的时间。C比汇编程序容易维护。
汇编器是比C更底层的编程语言,因此它非常适合直接对硬件进行编程。
硬件编程可以直接使用两种语言进行。在C语言中,您唯一无法做的就是访问CPU内核本身的堆栈指针和条件寄存器等。因此,如果通过硬件编程来表示与自己的CPU进行通信,那么是的,汇编器所允许的范围比C多得多。如果您的意思是访问外部硬件,那么汇编器对C而言就没有好处。但是也许有缺点,因为通常很难编写特定外部设备的通用汇编代码,而不是通用C代码。
暗示您可以使用内存,中断,微寄存器等的灵活性更高。
这是不正确的。尽管您可能不得不依赖于特定于编译器的C代码(例如interrupt关键字),但是C也允许您执行所有这些操作。
最后,您需要了解两种语言才能对MCU进行编程,重点是C。
a = b[i] + c;
它比要加载b[i]
(需要计算)并c
放入寄存器(必须使其可用),添加和存储的指令要简单得多。
根据您需要采用的嵌入式方式,C会生成大型,缓慢的程序。这将明显增加该部分产品的成本。整个产品可能只是沧海一粟,也可能会彻底改变产品。是的,有人可能会说软件开发和维护的成本要便宜一些,如果真是太深了,而且其目标是低功耗,小巧而廉价,那么您在谈论的不是很多代码,那么这是对还是错。该代码大部分特定于该供应商或特定芯片,因此使用C语言具有零可移植性优势,无论如何您都必须重写每个目标。有了ARM的cortex-m系列产品,我们现在才开始能够使C与asm竞争,而不是人们没有在嵌入式产品中使用C或其他高级语言,
从专业上讲,C与ASM的争论总是归结为用C编写并在可以证明其合理性的地方使用ASM。您可以证明这一点。在嵌入式世界中,存在性能和尺寸。
您必须在此讨论中包括目标。尽管许多人将C与Microchip一起使用(较老的图片,而不是mips的pic32),却付出了巨大的代价,但对于编译器而言,它是一个可怕的指令集,非常有教育意义和有趣的指令集,但编译器不友好。msp430,avr,arm,thumb,mips对编译器都有利。8051也不错。
甚至超过了语言工具。在担心代码开发和管理成为问题的情况下,Esp需要使用工具来实现今天和明天。从业务角度来看,拥有一个由一组管理的单一源工具,甚至包括一个gcc mod,都是有风险的。您可能会发现不止一个汇编器,而且值得加入该团队的任何人都可以在周末鞭打一个汇编器(只要您编写的汇编不满意,宏也不会高兴)。对于asm和C,您都希望使用开放源代码工具(或您自己的内部工具),尽管机会更多,即使这意味着使用虚拟机运行10年的Linux发行版,也可以使用这些工具产品的寿命。
底线再次使用/学习/教导C和asm,从C开始并在可以证明其合理性的地方使用asm。
对于汇编,代码可维护性和性能之间不可避免地要折衷。您可以编写易于阅读/维护的程序集,也可以编写高度优化的代码。但是你不能两者都做。
对于C语言,折衷方案并没有完全消失,但它的影响要小得多-您可以编写易于阅读/维护的C语言,并对其进行合理优化。
一个优秀的汇编语言程序员几乎在所有时间都可以击败编译器,但是大多数时候,他们会故意选择编写易于阅读/维护的代码。因此,大多数时候,优秀的汇编语言程序员都会被编译器击败。
明智的方法是同时使用汇编语言和C语言(而不是仅使用汇编语言或仅使用C语言)-例如,对于优秀的汇编语言程序员会选择编写可维护/慢速代码的部分代码,请使用C语言,并在其中使用汇编语言。其余的(实际上是“高度优化且难以维护”的理由)。