時間:2008-09-01 13:10:00來源:ronggang
 圖2. ARM、X86上µC/OS-II中斷現場保護[/align]
  根據量化公式:
圖2. ARM、X86上µC/OS-II中斷現場保護[/align]
  根據量化公式:
   公式中以CPU時間來衡量微處理器體系結構的性能。其中前半部分是指令的執行時間,包括取指、分析、執行等,而后半部分表明如果指令是訪存指令則在cache不命中時CPU時間還應該加上訪存的時間。由于訪存速度遠遠大于CPU的執行速度,尤其是批量訪存指令,一旦遇到存儲器分體沖突,將等待更長的時間。而在ARM7TDMI、ARM9TDMI這些沒有cache的微處理器內核中,批量訪存指令的CPU時間公式就完全變成如下形式:
  公式中以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所示。
[align=center]
  因此,在這些處理器內核中在處理諸如任務切換和進入中斷的現場保護的批量訪存指令時,系統將等待,從而影響實時性。
  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所示。
[align=center] 圖3. µC/OS-II時鐘中斷處理
圖3. µC/OS-II時鐘中斷處理
標簽:
                                 
                            
傳動網版權與免責聲明:凡本網注明[來源:傳動網]的所有文字、圖片、音視和視頻文件,版權均為傳動網(www.cdcst56.com)獨家所有。如需轉載請與0755-82949061聯系。任何媒體、網站或個人轉載使用時須注明來源“傳動網”,違反者本網將追究其法律責任。
本網轉載并注明其他來源的稿件,均來自互聯網或業內投稿人士,版權屬于原版權人。轉載請保留稿件來源及作者,禁止擅自篡改,違者自負版權法律責任。
產品新聞
更多>2025-09-08
2025-08-06
2025-07-08
2025-06-30
2025-06-16
2025-06-09