补充：事件不仅包含中断和异常，还包含系统调用，这个属于用户主动请求的事件。
上一节，只有一个溢出异常，那么，如果很多异常、中断呢？（中断向量表）
另外，之前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内核源代码，使得软硬件对应上。
