一、嵌入式系統的實時性
嵌入式系統是以應用為中心，以計算機技術為基礎，并且軟硬件可裁剪，適用于應用系統對功能、可靠性、成本、體積、功耗有嚴格要求的專用計算機系統，而高實時性是嵌入式系統的基本要求。
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，只要對它們進行保護即可，從而能更進一步縮短中斷響應時間，大大縮短中斷響應時間，提高中斷實時性。
四、總結
傳統的中斷現場保護保存所有寄存器的內容，雖然使得程序的設計得到簡化，但是同時造成了多余的寄存器保護，增加了中斷響應的時間。有限中斷現場保護策略能夠根據具體中斷服務中所需要使用的通用寄存器而進行相應的有限的保護，縮短了現場保護的時間，使用戶中斷服務能夠盡早的到處理，提高了中斷實時性。但是同時，有限中斷現場保護的效率也受到中斷服務處理復雜程度以及編譯器性能的影響。對于中斷服務簡單，而對實時性要求高的中斷，效果較明顯，而對于復雜的中斷服務，需要的通用寄存器較多，從而中斷現場保護的寄存器也較多。而在同一中斷服務中，效率高的編譯器能夠在不犧牲代碼效率的情況下使用盡可能少的寄存器來完成中斷服務，從而減少了需要中斷現場保護的寄存器數，達到提高中斷實時性的要求。