编写固件:汇编还是高级? [英] Writing firmware: assembly or high level?

问题描述

相关:

• 测试固件
• 启动微控制器模拟器/模拟器
• 解释汇编代码

如果您正在为 微控制器编写代码如果您用汇编或 C 或其他高级语言编写，真正的区别是什么?如果您编写 C 代码，您将如何编译它?

If you are writing code for a microcontroller is there a real difference if you write in assembly or C or some other high level language? If you wrote C code, how would you compile it?

谢谢

推荐答案

几点意见:

1) 除非性能或优化限制需要，否则绝对不 组装.以下指标随组装一起飞速发展:

1) Absolutely not assembly unless performance or optimization constraints warrant it. The following metrics go through the roof with assembly:

• 是时候编写代码了
• 是时候调试它了
• 是时候测试一下了
• 是时候记录它了
• 是时候弄清楚(1 年后)你在编写代码时在做什么
• 犯错的机会

2) 我更喜欢 C++ 而不是 C，因为它的命名空间封装 &它促进了编译时面向对象的实践.C 有太多的机会出现全局变量和命名空间冲突.(实时 Java 会很好，但据我了解，它的要求仍然很高)

2) My preference would be C++ rather than C for its namespace encapsulation & its facilitation of compile-time object-oriented practices. C has too many opportunities for global variables and namespace collisions. (Real-time Java would be nice but from what I understand its requirements are still pretty high)

或者更确切地说是 C++ 的一个子集:排除异常、虚函数、运行时类型识别，以及大多数情况下的动态内存分配——基本上是在编译时未指定的任何内容，因为它通常需要大量额外资源在运行时.这就是 C++ 的膨胀".

Or rather a subset of C++: Exclude exceptions, virtual functions, run-time type identification, also dynamic memory allocation in most cases -- basically anything that's left unspecified at compile time, as it will usually require a lot of extra resources during runtime. That's the "bloat" of C++.

我已分别为 TMS320 和 MSP430 微控制器使用了 TI 和 IAR 的 C++ 编译器，并且通过适当的优化设置，它们在减少 C++ 开销方面做得非常出色.(特别是如果你明智地使用 inline 关键字来帮助它)

I have used both TI's and IAR's compilers for C++, for the TMS320 and MSP430 microcontrollers (respectively) and with proper optimization settings, they do a fantastic job of reducing the overhead you might expect from C++. (Especially if you help it out by judicious use of the inline keyword)

我什至使用模板来实现它们在编译时的一些好处，这些好处可以促进良好的代码重用:例如编写单个源代码文件来处理 8 位、16 位和 32 位 CRC；和 编译时多态性 允许您指定一个类的通常行为，然后重用它但覆盖它的一些功能.同样，TI 编译器通过适当的优化设置具有极低的开销.

I have even used templates for some of their compile-time benefits which promote good code reuse: e.g. writing a single source code file to handle 8-bit, 16-bit, and 32-bit CRCs; and compile-time polymorphism to allow you to specify the usual behavior of a class, and then reuse that but override some of its functions. Again, the TI compiler had an extremely low overhead with appropriate optimization settings.

我一直在为 Microchip PIC 寻找 C++ 编译器；我发现唯一一家生产的公司是 IAR.($$$ 一直是个障碍，但我希望有一天能买一份)Microchip C18/C30 编译器非常好，但它们是 C，而不是 C++.

I have been looking for a C++ compiler for the Microchip PICs; the only company I've found that produces one is IAR. ($$$ has been an obstacle but I hope to buy a copy sometime) The Microchip C18/C30 compilers are pretty good but they're C, not C++.

3) 关于编译器优化的一个特别警告:它可以/将会使调试变得非常困难；通常不可能单步执行优化的 C/C++ 代码，并且您的监视窗口可能会显示与您认为它们应该包含的未优化代码无关的变量.(一个好的调试器会警告你一个特定的变量已经被优化到不存在或被优化到一个寄存器而不是一个内存位置.许多调试器没有.>:(

3) A specific caveat about compiler optimization: it can/will make debugging very difficult; often it's impossible to single-step through optimized C/C++ code and your watch windows may show variables that have no correlation with what you think they should contain with unoptimized code. (A good debugger would warn you that a particular variable has been optimized out of existence or into a register rather than a memory location. Many debuggers do not. >:(

另外，一个好的编译器可以让您通过#pragmas 在函数级别选择/选择优化.我使用的那些只允许您在文件级别指定优化.

Also a good compiler would let you pick/choose optimization at the function level through #pragmas. The ones I've used only let you specify optimization at the file level.

4) 将 C 代码连接到程序集:这通常很困难.最简单的方法是制作一个具有您想要的签名的存根函数，例如uint16_t foo(uint16_t a, uint32_t b) {return 0;}，其中 uint16_t = unsigned short，我们通常明确表示位数.然后编译它并编辑它生成的程序集(只需确保保留代码的开始/退出部分)并小心不要破坏任何寄存器而不在完成后恢复它们.

4) Interfacing C code to assembly: This is usually difficult. The easiest way is to make a stub function that has the signature you want e.g. uint16_t foo(uint16_t a, uint32_t b) {return 0; }, where uint16_t = unsigned short, we usually make the # of bits explicit. Then compile it and edit the assembly it produces (just make sure to leave the begin/exit parts of the code) and be careful not to clobber any registers without restoring them after you are done.

内联汇编通常会出现问题，除非您正在做一些非常简单的事情，例如启用/禁用中断.

Inline assembly usually can have problems unless you are doing something very simple like enabling/disabling interrupts.

我最喜欢的方法是编译器内在函数/扩展 ASM"语法.Microchip 的 C 编译器基于 GNU C 编译器，它具有扩展 ASM"，它可以让你编写内联汇编的代码，但你可以给它很多提示来告诉它你正在引用哪些寄存器/变量，它会处理所有寄存器的保存/恢复，以确保你的汇编代码玩得很好"C. TI 的 TMS320 DSP 编译器不支持这些；它确实有一组有限的内在函数有一些用处.

The approach I like best is compiler intrinsics / "extended ASM" syntax. Microchip's C compiler is based on the GNU C compiler and it has "extended ASM" which lets you code bits of inline assembly but you can give it lots of hints to tell it which registers/variables you are referencing and it will handle all the saving/restoring of registers to make sure your assembly code "plays nice" with C. TI's compiler for the TMS320 DSP doesn't support these; it does have a limited set of intrinsics which have some use.

我使用汇编来优化一些经常执行的控制循环代码，或者计算 sin()、cos() 和 arctan().但否则我会远离汇编并坚持使用高级语言.

I've used assembly to optimize some control loop code that got executed frequently, or to calculate sin(), cos(), and arctan(). But otherwise I'd stay away from assembly and stick with a high-level language.

这篇关于编写固件:汇编还是高级?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！