前言

笔者在 《程序是如何在 CPU 中运行的(二)》中从 PC 指针寄存器的角度分析了一级函数调用和二级函数调用执行的过程，那么中断服务子程序又是如何被执行的呢？两者的相同点和不同点是什么呢？该篇文章笔者将详细地阐述这个概念。

中断的概念

当 CPU 正在处理某件事情的时候，外部发生的某一事件请求 CPU 迅速去处理，于是，CPU 暂时中止当前的工作，转去处理所发生的事件。中断服务处理完该事件以后，再回到原来被中止的地方，继续原来的工作，这样的过程称之为中断，示意图如下：



js强制中断function_堆栈

中断执行示意图

中断响应及处理过程

回顾函数调用的过程，子程序由主程序进行调用，从而完成执行。但是中断服务子程序并没有被主程序进行调用，中断服务子程序的执行是通过中断请求完成的，也就是说中断服务子程序可以发生在主程序执行的随意位置，那现在就面临一个问题了，如果当CPU 正在执行函数调用的子程序的内容的时候产生了一个中断请求，那么这个时候 CPU 将暂停执行函数调用的子程序的内容，转而去执行中断服务子程序的内容，如果不进行额外的处理，那么函数调用的子程序的相关数据将丢失，因此在执行中断服务子程序之前，CPU 必须要保存发生中断的那个地方的相关信息，这个操作用专业的术语来讲就是保护现场，保护现场之后，CPU 将执行中断服务子程序的内容，执行完中断服务子程序的内容之后，CPU 要回到刚刚暂停的地方继续执行，另外在返回之前，CPU 还要进行恢复现场，恢复现场之后，就可以返回到暂停的地方继续执行了，下面是整个过程的示意图：



js强制中断function_js强制中断function_02

中断响应示意图

通过上述示意图我们也可以看到在返回地址这个地方，中断服务子程序和函数调用子程序的返回地址所遵循的原理是一样的，函数调用子程序的返回地址是函数调用指令的下一条指令的地址，而在上述示意图中的 N 和 N+1 的含义也是类似的，当 CPU 执行到第 N 条指令的时候，CPU 接收到了一个中断请求，在执行完第 N 条指令之后，转而去执行中断服务子程序的内容，然后中断服务子程序的返回地址对应的是第 N+1 条指令的地址。

中断的堆栈占用

在刚刚所述的内容中，说到 CPU 在执行中断服务子程序的内容之前，需要保护现场，那保护现场这个操作具体是怎么实现的呢？这个时候，就要用到我们的堆栈了。在这里拿 ARM Cortex M3 举例，在响应中断时所做的第一个操作就是保护现场，它会依次把 xPSR,PC,LR,R12以及 R3-R0 由硬件自动压入适当的堆栈中，注意，这里是自动压入堆栈，也就是说如果我们看对应的汇编代码是看不到这部分压栈操作的。另外，我们知道对于 ARM Cortex M3 的堆栈指针来说，它存在两个，一个是主堆栈指针(MSP)，一个是线程堆栈指针(PSP),其中主堆栈指针是复位后默认使用的堆栈指针，用于操作系统内核和中断处理程序，线程堆栈指针(PSP)是由用户的应用程序代码所使用。那么在执行现场保护时将相关寄存器的值压入堆栈，应该使用哪个堆栈指针呢？这也是存在一个原则的，如果在响应中断时，当前的代码正在使用线程堆栈(PSP)，那么将使用线程堆栈指针(PSP)进行压栈，否则将使用主堆栈指针(MSP)。另外在 CPU 进入中断服务子程序之后，所涉及的堆栈操作所使用的堆栈一直是主堆栈指针(MSP)。为了更直观的展示这个过程，下图是发生中断请求后，堆栈的变化示意图：



js强制中断function_js强制中断function_03

中断堆栈调用示意图

通过上图我们可以很清楚地看到在响应中断时产生的保护现场操作，堆栈明显增长了，而在执行完中断服务子程序的内容之后，又将执行恢复现场的操作，这个时候堆栈的内容又减少了。为了更清楚地展示压入堆栈寄存器的操作，笔者在这里也给出上述图中堆栈粉色部分的详细内容，图片如下：



js强制中断function_js强制中断function_04

保护现场堆栈内容

上述就是保护现场时所压入堆栈的相关寄存器，另外还需注意的一点是当所涉及的中断服务子程序逻辑比较复杂的时候，就需要更多的寄存器了，这个时候就需要用到 R4-R11 了，但是这部分寄存器是不能进行自动压栈的，也就是说如果在中断服务子程序中使用到这部分寄存器的时候就需要进行手动压栈，那么这部分的压栈操作在汇编层面就能看到了。

中断向量表

在上述所阐述的内容中，我们知道了中断会在主程序的任意发生中断请求，从而执行中断服务子程序的内容，也阐述了在执行中断服务子程序的内容之前需要进行保护现场的操作，以及执行完中断服务子程序的内容之后需要进行恢复现场。现在我们再来思考，在 CPU 中，中断源不止一种，可以是按键按下所触发的一个外部中断，也可能是在使用串行通信时，收到数据所触发的一个中断，亦或是在 CPU 中定义的一个定时中断由于设置的时间到了而触发的定时中断，这个时候，就浮现一个问题了，要如何将这一个一个的中断源与其各自的中断服务子程序所一一对应起来呢？换句更为通俗的话来讲就是当 CPU 接收到一个中断信号时，CPU 将如何找到对应的中断服务子程序进行执行呢？这个时候，就需要中断向量表了，下面是中断向量表的特点：

  • 中断向量表在 CPU 中是一段连续的存储空间
  • 中断向量表在 CPU 复位后有默认的起始地址
  • 每一个中断在中断向量表中都有对应的表项，该表项的值为该中断源对应的中断服务程序的地址
  • 由程序代码确定中断向量表中的每个表项

上述特点说中断向量表都存在默认的起始地址，在这里依旧拿 ARM Cortex M3 内核来看，它的中断向量表默认的起始地址是从地址 0x0000 0000 开始的，如下图所示：



js强制中断function_子程序_05

中断向量表

当然这只是一部分，并不是全部的表项。有了中断向量表之后，那么当 CPU 接收到中断请求的时候，就会根据这个中断请求的信号去查这个表，从而查找到其所对应的中断服务子程序的地址，然后将这个地址赋值给 PC 指针寄存器就，那么 CPU 就可以完成中断服务子程序的执行了，对于 PC 指针寄存器不是太清楚地朋友可以看笔者的这篇文章 《程序是如何在 CPU 中运行的(二)》。

中断服务函数的写法

中断服务函数的写法不同的 CPU 有各自不同的写法，对于 ARM Cortex M3 的 CPU 来说，因为其内核的特点，在执行完中断服务函数后的返回指令与普通函数调用的返回指令是一样的，因此中断服务函数的写法与 C 语言中普通函数的定义没有区别，比如下面是 STM32F103 的一个外部中断的服务函数

void EXTI0_IRQHandler(void){
    /* 确保是否产生了中断 */
    if(EXTI_GetITStatus(EXTI_Line0) != RESET) 
    {   
        /*用户代码*/
        /*清除中断标志位*/
        EXTI_ClearITPendingBit(KEY1_INT_EXTI_LINE);     
    }  
}

通过上述的代码我们可以看到中断服务函数的另一个特点，就是它的返回值和形参都为 void ，这也是由原因的，因为中断服务函数本来就不是由主程序进行调用的，既然中断服务函数不会被其他函数所调用，那么其返回值和形参自然是 void 了，要使得 CPU 能够找到中断服务子程序，那么这个函数的函数名不是随意命名的，比如这里的 EXTI0_IRQHandler,这个函数名与中断向量表中表项的值是对应起来的，因为函数名从数值上看代表的是函数的入口地址。
上述说到是因为 ARM Cortex M3 的 CPU 在处理中断服务函数的返回地址时用的指令和普通函数调用时的返回地址的指令一致，所以才能够使中断服务函数的写法与普通 C 语言函数没有差异，下面举一个 51 单片机的定时器中断服务函数的例子：

void InterruptTimer0() interrupt 1{
    /*省略*/
}

上述的这个中断服务函数， InterruptTimer0可以任意命名，但是括号后面的是有严格规定的，为了 51 单片机能够进行中断处理，C51 编译器对函数进行了扩展，增加了一个扩展关键字interrupt，从而让 CPU 知道这个是一个中断服务函数。

中断的嵌套

C 语言函数能够进行嵌套调用，同样的中断服务函数也能够进行嵌套，同样的用一张图来表明中断的嵌套：



js强制中断function_子程序_06

中断嵌套示意图

可以看到中断的嵌套也是在消耗堆栈的，和使用函数嵌套调用一个道理，这里需要注意的是中断是存在优先级的，如果发生了一个比当前执行的中断优先级低的中断请求，那么新产生的中断请求会等待正在执行的中断执行完成之后才开始响应新的中断，如果产生的中断的优先级比当前的优先级要高，那么也就会像上图所示一样进行执行。另外需要注意的是，中断的优先级是有限的，也就是说中断嵌套的层数是有限的，如果再考虑堆栈溢出的话，那么中断嵌套的层数还和堆栈的大小有关。

总结

上述就是关于中断的相关内容，简单地叙述了中断是如何响应的，如何执行保护现场和恢复现场的操作，CPU 如何根据中断向量表找到对应的中断服务函数，以及中断的嵌套，这就是这次分享的全部内容啦~