嵌入式Linux中断现场保护怎么优化？ - EDA365电子论坛网

一、嵌入式系统的实时性

嵌入式系统是以应用为中心，以计算机技术为基础，并且软硬件可裁剪，适用于应用系统对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统，而高实时性是嵌入式系统的基本要求。

IEEE（美国电气电子工程师协会）定义实时系统为“那些正确性不仅取决于计算的逻辑结果，也取决于产生结果所花费的时间的系统”。实时系统一般可分为硬件实时和软件实时这两大类：硬实时系统有一个强制性的、不可改变的时间限制，它不允许任何超出时限的错误。超时错误会带来损害甚至导致系统失效、或者系统不能实现它的预期目标。软实时系统的时限是柔性灵活的，它可以容忍偶然的超时错误。失败造成的后果并不严重，仅仅是轻微的降低了系统的吞吐量。

二、中断响应时间

中断的实时性是实时系统的一个重要方面。中断响应时间是影响中断实时性的主要因素。中断响应定义为从中断发生到开始执行用户的中断服务代码来处理这个中断的时间[1>，其中包括中断延迟时间和保护中断现场的时间。所有实时系统在进入临界区代码段之前都要关中断，执行完临界代码之后再开中断。中断延迟时间即是从发出中断请求到任务开中断的这段时间[1>。保护中断现场有两个作用。首先是为了保护中断前任务的现场。其次，如果发生中断嵌套，还必须保护上层中断的现场。因此，整个中断响应过程如图1所示。要让中断服务尽快得到处理，就必须减少中断响应时间。但是从图中可以看出，中断延迟时间是由中断前任务决定的，在进入中断时只能通过尽量缩短中断现场保护的时间来达到减少中断响应时间，从而提高中断实时性。

图1. 中断响应示意图

三、中断现场保护的改进

3.1 传统中断现场保护方法

对于现在大多数嵌入式操作系统，在进入中断时首先做的第一件事就是保护中断发生前的现场，即保存返回地址、程序状态字、堆栈指针以及所有通用寄存器到中断堆栈，以防止用户中断服务子程序对中断返回后现场的破坏。以μC/OS-II微内核为例，在arm和X86两种体系结构微处理器上进入中断后保存现场的过程如图2所示。从代码中可见，两种不同的体系结构中，为保护现场，都需要执行三条访存指令，其中一条为批量访存指令（STMFD SP!,｛R0-R12｝和PUSHA）用以保护通用寄存器R0-R12和AX，CX，DX，BX，SP，BP，SI，DI。

图2. arm、X86上μC/OS-II中断现场保护

根据量化公式：

公式中以CPU时间来衡量微处理器体系结构的性能。其中前半部分是指令的执行时间，包括取指、分析、执行等，而后半部分表明如果指令是访存指令则在cache不命中时CPU时间还应该加上访存的时间。由于访存速度远远大于CPU的执行速度，尤其是批量访存指令，一旦遇到存储器分体冲突，将等待更长的时间。而在ARM7TDMI、arm9TDMI这些没有cache的微处理器内核中，批量访存指令的CPU时间公式就完全变成如下形式：

因此，在这些处理器内核中在处理诸如任务切换和进入中断的现场保护的批量访存指令时，系统将等待，从而影响实时性。

3.2 中断现场保护的优化策略

中断现场保护中，保护返回地址、程序状态字、堆栈指针是必需的，否则中断结束后将无法顺利返回。而保护通用寄存器的目的在于防止用户中断服务子程序使用其中的寄存器，造成对原有内容的覆盖而在中断返回后任务执行出错。因此在中断里对通用寄存器的保护完全可以取决于中断服务子程序对通用寄存器的使用情况，仅仅保存中断服务子程序中所用到的有限的几个通用寄存器，而不必保存所有通用寄存器。以arm体系结构为例，在用户模式下可用的通用寄存器为R0～R12，R13用作堆栈指针、R14为返回地址、R15用作PC，如果在中断服务子程序中只用到R0～R12中的一小部分，则在中断到来时可以仅仅只保存通用存器中的这一小部分，从而能够减少访存时间，最终达到缩短中断响应提高中断实时性的目的。

在实际情况中，这种策略是具有可行性的。首先，每个中断服务子程序中所需要的通用寄存器是可知的。在使用汇编语言编写用户中断服务子程序时，所需要的通用寄存器由程序员控制，使用C语言则由编译器决定具体使用到哪几个通用寄存器。其次，在现有的嵌入式操作系统中，往往要求中断服务子程序尽可能的短小，例如在Linux中，把中断服务子程序分成Bottom Half和Top Half。因此，在大多数中断服务子程序中并没有用到所保护的全部通用寄存器，造成对其余通用寄存器的多余保护。

3.3 μC/OS-II时钟中断现场保护优化

时钟中断是操作系统中比较重要的一个部分，也是实时性要求较高的部分，在UNIX中时钟中断的优先级定义为6，仅次于最高优先级。以μC/OS-II时钟中断处理为例，中断处理过程如图3。μC/OS-II时钟中断服务中，首先要对中断嵌套计数器OSIntNesting进行加1操作，防止在嵌套的中断中进行任务调度;随后调用OSTimeTick（）对每个睡眠任务的OSTCBDly进行减1以及对系统时间OSTime加1操作;最后调用OSIntExit（）进行任务调度，如果不需要任务切换则返回到中断服务程序中。可见在时钟中断处理中，操作最多的集中在OSTimeTick（）和OSIntExit（）这两个函数上。通过armCC编译器的-s选项对两者进行编译，在得到的汇编代码中，前者需要使用R0、R1、R4-R7，后者需要R0-R3，没有使用R8-R12，而OSIntNesting++的操作也完全可以使用R0-R7进行，这样，在进入中断处理时，需要保存的通用寄存器仅仅为R0-R7。因此对图3中的①进行改写得到的保护中断现场的代码如图4所示。

图3. μC/OS-II时钟中断处理

图4 μC/OS-II时钟中断现场保护

μC/OS-II其他的中断处理与时钟中断相似，仅仅需要把OSTimeTick（）替换成对应的处理，如果能在不牺牲代码效率的情况下，将相应处理集中到R0-R3这几个寄存器中，则该中断处理中，仅仅使用R0-R3，只要对它们进行保护即可，从而能更进一步缩短中断响应时间，大大缩短中断响应时间，提高中断实时性。

四、总结

传统的中断现场保护保存所有寄存器的内容，虽然使得程序的设计得到简化，但是同时造成了多余的寄存器保护，增加了中断响应的时间。有限中断现场保护策略能够根据具体中断服务中所需要使用的通用寄存器而进行相应的有限的保护，缩短了现场保护的时间，使用户中断服务能够尽早的到处理，提高了中断实时性。但是同时，有限中断现场保护的效率也受到中断服务处理复杂程度以及编译器性能的影响。对于中断服务简单，而对实时性要求高的中断，效果较明显，而对于复杂的中断服务，需要的通用寄存器较多，从而中断现场保护的寄存器也较多。而在同一中断服务中，效率高的编译器能够在不牺牲代码效率的情况下使用尽可能少的寄存器来完成中断服务，从而减少了需要中断现场保护的寄存器数，达到提高中断实时性的要求。