嵌入式C

嵌入式软件分析验证工具系列之——

C，在嵌入式软件领域具有相当的代表性——即使是采用汇编，也都能在C中找到相对应的实现方式，不同的只是细微的效率差别；况且，嵌入式C编译器一般都支持inline assembly，可以在C中直接使用汇编语句。

作为构造嵌入式系统的C语言，利用C的灵活性，扩展出许多不同于ANSI C的特性，这使得开发一个嵌入式C的模型检验器1变得困难。在研究嵌入式软件的模型检验器所面临的许多困难，其实是模型检验技术抽象本质的必然结果，它不可能关注太多的细节，尤其是数据流方面（像一般的协议、驱动器，关注的是时序，是控制流），而这正是嵌入式代码关注的。这一事实在为微控制器如ATmega 16编写的C代码上可能不是很明显，而在为ADSP这样的数字信号处理上的C代码身上则体现的相当突出——这些C代码往往是某个信息处理算法的实现，大量、频繁的数据复制、移动、计算。B. Schlich 对此作出了全面、学术的分析：Model checking C source code for embedded systems(2009,cited 22 in Google)。

就开发一个特定领域应用软件的静态分析器，以汇编代码为对象比以C代码为对象更加合适，因为简单。 选择的理由只有一个：就是通用。如果用得不多，共性不多，就没有理由。当然，选择C，更便于理解、辅助分析、分析结果的反馈描述也容易些。

所以，在考虑嵌入式C时，还是应当以找共性为主，如下：

1、直接硬件访问。这在代码中仍然是以向某个内存地址赋值表现的，往往包含指针（作为地址）运算；

2、并行硬件控制。这在代码中以编译器特定的语法规则表现，如用interrrupt 标识中断服务例程。这些construct添加进来后不会对代码的静态属性有任何影响，影响的是代码的动态属性，比如会影响代码的Promela模型。

3、硬件相关副作用。这指的是某个看似平常的变量，在代码中并没有赋值操作，但是由于映射到某个硬件端口，在代码外部被硬件修改，而导致数据流属性不同于静态分析得到的属性。

后两条嵌入式C特殊的“共性”，可以称之为domain-specific；而第一条，只需要对一般的ANSI C分析工具做功能增强，强化指针操作的解析和分析。