PCB论坛网

 找回密码
 注册
查看: 1706|回复: 0

养成良好的嵌入式C代码编码习惯要遵循哪些规则?

[复制链接]
发表于 2019-1-17 17:49:22 | 显示全部楼层 |阅读模式


Cortex-M这类微控制器编程通常采用C代码,那么编程人员如何编写代码才能让C编译器产生高质量底层代码就成为一个很重要的话题。这里所说的高质量底层代码是指既达到编程人员意图又方便编译器优化的代码。

本文将从编写利于优化的源代码,节省栈和内存空间,函数原型,整型和位取反,同时读写变量的保护,不进行初始化的变量这几个方面来讨论如何编写良好的嵌入式C代码。

编写利于优化的源代码
我们在编写源代码的时候如果能够遵循以下几点,可以让编译器更好的对代码进行优化:

1)局部变量(自动变量和参数)比静态或全局变量要更好。为什么这么说呢,因为优化器会假定任何一个函数都可能修改静态或全局变量。当局部变量的生命周期结束的时候,它所占据的内存就可以被其它变量使用,而全局变量在整个程序的生命周期内都不会释放它所占据的内存空间。

2)避免用&运算符取局部变量的地址。这里有两个原因会导致该操作的效率低下。首先,变量必须放在内存中,不能放在处理器的寄存器中,这将导致更长更慢的代码效率。其次,优化器不再假设其它的函数,因此不会影响到该变量。

3)编译器的内联函数能力。为了最大限度的影响编译器的内联转换,我们最好把那些多个模块都用到的小函数写在头文件中而不是实现文件中。

节省栈和内存空间
以下的编程技术可以让我们节省内存和栈空间:

1)如果栈空间有限,那么我们就要尽量避免长的调用链和递归函数。

2)避免使用大的聚合类型(比如结构体)作为参数或者返回类型。为了节省栈空间,我们应该更多的使用指针来代替这种聚合类型。

函数原型
有两种函数的定义和声明方式可以使用。一种是原型风格,一种是Kernighan & Ritchie C风格。两种风格都是可以的,但强烈建议应用原型风格,也就是说对每一个公共函数都在相应的头文件中提供一个原型声明。

这是因为编译器对应用Kernighan & Ritchie C风格的参数不进行类型检查。应用原型风格在某些情况下将产生高效的代码,因为它不需要进行参数类型提升。为了保证所有的公共函数都在定义之前声明过,可以打开编译器选项 Project>Options>C/C++ Compiler>Language 1>Require prototypes

以下是两种风格的示例

1)原型风格:

原型风格中,必须写明每个参数的类型。

int Test(char, int); /* 声明 */
int Test(char ch, int i) /* 定义 */
{
return i - ch;
}

2)Kernighan & Ritchie风格

Kernighan & Ritchie风格中,不需要进行函数原型声明。取而代之的是一个空参数列表的函数声明。函数的定义也有些不同。

int Test(); /* 声明 */
int Test(ch, i) /* 定义 */
char ch;
int i;
{
return i - ch;
}

整型和位取反
在某些情况下,整数类型和它们的转换提升规则会导致难以理解的行为。这经常出现在赋值或者条件表达式中,这里涉及不同长度类型的数据和逻辑操作尤其是位取反操作。这里的类型也包括常数类型。例如:1个8位的字符类型,1个32位的整数类型,按照二进制补码操作。

void F1(unsigned char c1)
{
if (c1 == ~0x08);
}

这里,测试条件总是false。因为右边的0x08 = 0x00000008,~0x00000008 = 0xFFFFFFF7。左边的c1是1个8位无符号字符类型,因此它不可能比255大,也不可能是负数,这就意味着它的高24位不可能置1。所以这个测试条件总是false的。

同时读写变量的保护
在中断程序或者单独线程中用到的变量经常是异步读写的,它们必须进行适当地标记和适当的保护。编译器应用volatile关键字对这类变量进行标记。这个关键字通知编译器该对象的值无任何持久性,不要对它进行任何优化。

它迫使编译器每次需要该对象数据内容的时候都必须读该对象,而不是只读一次数据并将它放在处理器的寄存器中以便后续访问之用。



回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|小黑屋|手机版|PCB设计论坛|EDA论坛|PCB论坛网 ( 沪ICP备05006956号-1 )

GMT+8, 2024-4-18 06:54 , Processed in 0.135157 second(s), 20 queries .

Powered by Discuz! X3.4

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表