嵌入式Linux中断现场保护的改进方法
根据量化公式：
公式中以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，只要对它们进行保护即可，从而能更进一步缩短中断响应时间，大大缩短中断响应时间，提高中断实时性。
四、总结
传统的中断现场保护保存所有寄存器的内容，虽然使得程序的设计得到简化，但是同时造成了多余的寄存器保护，增加了中断响应的时间。有限中断现场保护策略能够根据具体中断服务中所需要使用的通用寄存器而进行相应的有限的保护，缩短了现场保护的时间，使用户中断服务能够尽早的到处理，提高了中断实时性。但是同时，有限中断现场保护的效率也受到中断服务处理复杂程度以及编译器性能的影响。对于中断服务简单，而对实时性要求高的中断，效果较明显，而对于复杂的中断服务，需要的通用寄存器较多，从而中断现场保护的寄存器也较多。而在同一中断服务中，效率高的编译器能够在不牺牲代码效率的情况下使用尽可能少的寄存器来完成中断服务，从而减少了需要中断现场保护的寄存器数，达到提高中断实时性的要求。
评论