補充：事件不僅包含中斷和異常，還包含系統調用，這個屬于用戶主動請求的事件。

---

上一節，只有一個溢出異常，那么，如果很多異常、中斷呢？（中斷向量表）

另外，之前0號地址只能存儲兩條指令，如果需要更多指令怎么辦？（地址的位置以及對應程序大小應該更靈活）

注意，中斷服務程序包含（保存現場，調用處理方法（主體），恢復現場）

我們在遇到中斷之后，需要執行的步驟，我們簡化一下

CPU做一些硬件處理工作（識別中斷源，關中斷，當前指令（或下一條指令）地址壓棧，FLAGS寄存器壓棧）

找到處理中斷的程序地址（這里的程序是中斷服務程序）

執行中斷服務程序（包含保護現場，執行處理程序（這個才是主體部分），恢復現場，返回原程序）

繼續執行原有程序

在不同的時代，中斷的處理都是這個過程，只不過每個過程具體的執行發生了變化，且越來越復雜，我們依次看一下。

1 時代1：UNIVAC時代，僅有固定地址中斷處理

在最初的計算機時代，只有很少的內部中斷和外部中斷。
內個時候的中斷服務程序，是固定的地址，并且程序的大小也相對受限。

例如出現了算數溢出，那么就會跳轉到地址0執行中斷服務程序。

不僅如此，這個時候的中斷服務程序幾乎是

• 固定地址
• 固定大小

因此靈活性很差，不過由于很少，所以還好。

到了后來，中斷越來越多，因此就有了中斷向量表，下面看看8086時代吧。

2 時代2：8086時代，實模式 + 中斷向量表

這個時代，中斷已經較多了，管理中斷的方式也更加靈活了。

8086采用的是實模式，也就是說，進入CPU指令中的地址，就是實際的物理地址。

在8086的1MB內存中，有專門的中斷向量表區，從地址0開始的1K字節，它用于存放中斷服務程序的地址，也就是存放CS:IP。

每對CS:IP占用4個字節，因此1KB的空間，最多可以支持256種中斷。

CS:IP，CS在前，IP在后，因此CS在高地址，IP在低地址，又因為是小端模式，因此IP的高字節是高位，低字節是低位；CS同理。

這樣一來，實際的中斷服務程序的位置，是根據這些CS:IP的值確定的，而它們在內存中是可以修改的，因此

• 中斷服務程序的位置可變
• 程序的大小可改

并且這些中斷服務程序的位置是任意的，只要能夠與中斷向量表對應上即可。

同時，不同的中斷服務程序，位置沒有關聯，放哪里都行。在實模式的8086之下，只需要CS:IP就可以確定實際內存的位置。

在這個時代，中斷服務程序的位置了大小更加靈活，變成了間接獲取，因為加了一個中斷向量表。

注意，這個時候有5種類型的中斷，并不是5個中斷，這個時候涉及到的內部中斷有4個，外部中斷有1個，而這個外部中斷，是8259A芯片發出的，該芯片外面可以連接很多個外設。

我們來看看這個時代中斷處理的示意圖。

3 時代3：80386時代，保護模式 + 中斷向量表

這個時代就有點復雜了，引入了保護模式，同時增加了一些中斷類型，這也是Linux 0.11內核對應的CPU。

圈住的部分是80386支持的中斷類型，int0 ~ int16，其中int15未定義，可以在手冊中查到。

3.1 保護模式下的尋址方式

首先，保護模式下，依然是CS:EIP的形式，但是由于EIP已經足夠尋址4GB，因此CS不再作為位數擴展的功能了，它的功能發生了改變。

在保護模式下，段寄存器依然是16位，它們變成了段選擇子寄存器，先從最簡方式描述地址的生成方法：

通過段選擇子寄存器找到8字節大小的段描述符

根據段描述符的內容獲取段基址（32位）

段基址和EIP組合（==應該就是相加吧？==基址 + 偏移地址），得到地址

注意： 目前可以知到這個地址是給CPU看的，它應該是虛擬地址，現在先不管，先當成通過這個地址就能夠訪問到內存的指定位置。

是不是比實模式復雜多了，下面，進一步展開細節。

通過段選擇子寄存器（此后均以CS舉例說明），怎么找到對應的段描述符？

計算機啟動進入實模式

填好GDT

設置好GDT的初始地址放入GDTR寄存器中

---

在保護模式下， CS + GDTR獲取對應的描述符（0~8191），這樣，我們就獲取了代碼段的描述符了。

接下來我們看看這個描述符

這個描述符有8192個，也就是2^13，而一個描述符有2^3 = 8個字節，因此一共占用了2^16個內存單元，也就是64KB，CS寄存器是16位的，這是它能夠訪問的極限，這樣，通過GDTR基址 + CS偏移的方式，能夠訪問到每一個描述符表。

再看每一個描述符的結構

它有8個字節的大小，其中有四個字節是段基址，就是這個段基址與EIP組合，形成最終的要訪問內存的（虛擬）地址。其他的自己還涉及到權限以及界限，先不管是干啥的。

段描述符的內容是什么，怎么獲取段基址

上面已經說明了。

3.2 保護模式下的中斷操作

上面一小節，經歷了一系列復雜過程，終于說明了保護模式下如何尋址，真的很復雜啊……下面說明一下中斷操作過程。其實最主要說明的還是找中斷服務程序位置這個過程。

在保護模式下，也有一個IDTR中斷描述符表寄存器，還有一個IDT中斷描述符。

這個IDT同樣是支持256種類型的中斷的，每個描述符表項占8個字節，因此一共占用2KB。

IDTR提供的是IDT的基址，然后CPU獲取中斷號之后，根據中斷號 * 8 + IDTR定位對應的描述符。

對于中斷描述符

• 字節0167四個字節對應的是32位地址，也就是EIP的值
• 字節23對應的是CS的值
• 有了CS:EIP就可以通過上一小節的方式找到對應的地址，從而找到中斷服務程序入口地址
  （這個過程其實與CS:IP類似，只不過麻煩了點）

折騰了這么一大圈，終于找到中斷服務程序了……

3.3 小結

這個太復雜了，我們簡單總結一下吧。

首先，保護模式下的尋址方式更復雜了，引入了全局描述符表，雖然依然是CS:EIP，但是其計算方式更加復雜了。

其次，保護模式下的中斷處理更復雜了

• 以前固定位置的中斷向量表，變成了任意位置的中斷描述符表IDT，通過IDTR和中斷類型號計算得到中斷描述符
• 再通過中斷描述符的內容獲取CS:EIP，再獲取對應中斷服務程序的入口地址

我們可以看到，模式越來越復雜，間接程度越來越高，設置的自由度提高，安全性也提高了。

思想：太固定死板怎么辦？加個固定的中轉站！通過改變中轉站，來實現靈活地分配目標

這幾個時代的發展過程，可以說中轉站越來越多，越來越復雜，靈活度越來越高。

小結

本篇內容，貫徹的是中斷處理的找中斷服務程序的過程。

可以看到

UNIVAC時代非常直接地找到地址

8086時代提供了固定位置中斷向量表，間接地找到CS:IP，尋址方式是直接的

80386時代提供了任意位置的中斷描述符表，間接地獲取CS:EIP，尋址方式也是間接的，需要通過全局描述符表GDT獲取段基址，從而獲取內存地址

不管怎樣，時代的發展使得根據中斷類型號，找到中斷服務程序這個過程越來越復雜，靈活度也越來越高。

后面會介紹中斷處理的其他過程，最后結合Linux 0.11內核源代碼，使得軟硬件對應上。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的x86异常处理与中断机制（2）中断向量表的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。