中斷中有些問題需要面對。
隔離變化
不知道您有沒有意識到，中斷處理前面這部分的設計是何等的簡單優美。人是高度智能化的，能夠對遇到的各種意外情況做有針對性的處理，計算機相比就差距甚遠了，它只能根據預定的程序進行操作。對於計算機來說，硬件支持的，只能是中斷這種電信號傳播的方式和CPU對這種信號的接收方法，而具體如何處理這個中斷，必須得靠操作系統實現。操作系統支持所有事先能夠預料到的中斷信號，理論上都不存在太大的挑戰，但在操作系統安裝到計算機設備上以後，肯定會時常有新的外圍設備被加入系統，這可能會帶來安裝系統時根本無法預料的“意外”中斷。如何支持這種擴展，是整個系統必須面對的。
而硬件和軟件在這裡的協作，給我們帶來了完美的答案。當新的設備引入新類型的中斷時，CPU和操作系統不用關注如何處理它。CPU只負責接收中斷信號，並引用中斷服務程序；而操作系統提供默認的中斷服務——一般來說就是不理會這個信號，返回就可以了——並負責提供接口，讓用戶通過該接口註冊根據設備具體功能而編制的中斷服務程序。如果用戶註冊了對應於一箇中斷的服務程序，那麼CPU就會在該中斷到來時調用用戶註冊的服務程序。這樣，在中斷來臨時系統需要如何操作硬件、如何實現硬件功能這部分工作就完全獨立於CPU架構和操作系統的設計了。
而當你需要加入新設備的時候，只需要告訴操作系統該設備佔用的中斷號、按照操作系統要求的接口格式撰寫中斷服務程序，用操作系統提供的函數註冊該服務程序，設備的中斷就被系統支持了。
中斷和對中斷的處理被解除了耦合。這樣，無論是你在需要加入新的中斷時，還是在你需要改變現有中斷的服務程序時、又或是取消對某個中斷支持的時候，CPU架構和操作系統都無需作改變。
保存當前工作“現場”
在中斷處理完畢後，計算機一般來說還要回頭處理原先手頭正做的工作。這給中斷的概念帶來些額外的“內涵”。注一“回頭”不是指從頭再來重新做，而是要接著剛才的進度繼續做。這就需要在處理中斷信號之前保留工作“現場”。“現場”這個詞比較晦澀，其實就是指一個信息集，它能反映某個時間點上任務的狀態，並能保證按照這些信息就能恢復任務到該狀態，繼續執行下去。再直白一點，現場不過就是一組寄存器值。而如何保護現場和恢復場景是中斷機制需要考慮的重點之一。
每個中斷處理都要經歷這個保存和恢復過程，我們可以抽象出其中的步驟：
1. 保存現場
2. 執行具體的中斷服務程序
3. 從中斷服務返回
4. 恢復現場
上面說過了，“現場”看似在不斷變化，沒有哪個瞬間相同。但實際上組成現場的要素卻不會有任何改變。也就是說，只要我們保存了相關的寄存器狀態，現場就能保存下來。而恢復“現場”就是重新載入這些寄存器。換句話說，對於任何一箇中斷，保護現場和恢復現場所做的都是完全相同的操作。
既然操作相同，實現操作的過程和代碼就相同。減少代碼的冗餘是模塊化設計的基本準則，實在沒有道理讓所有的中斷服務程序都重複實現這樣的功能，應該將它作為一種基本的結構由底層的操作系統或硬件完成。而對中斷的處理過程需要迅速完成，因此，Intel CPU的控制器就承擔了這個任務，非但如此，上面的所有步驟次序都被固化下來，由控制器驅動完成。保存現場和恢復現場都由硬件自動完成，大大減輕了操作系統和設備驅動程序的負擔。
原文地址：卿萃科技FPGA極客空間 微信公眾號
閱讀更多 卿萃科技FPGA 的文章
