5.2 中断处理流程

5.2 中断处理流程

本节摘要：从请求被受理到断点返回，一次中断要经过响应判定、隐操作、现场保护、服务执行、现场恢复五段流水——硬件自动做的那几步是机制的核心，服务程序补做的那几步是可靠性的关键。

上一站备好了向量表这张通讯录，本站沿着主线把一次中断的旅程逐拍走完。这一站与 2.2 的总线时序并列为本册最值得逐帧理解的内容——所有"中断为什么怪"的问题，答案都藏在这条流水线的某个环节里。

一次中断的完整旅程

第一段：响应判定。 处理器不是随时都能被拽走。一次可屏蔽中断要凑齐三个条件：当前指令执行完毕（处理器只在指令边界接待中断）、INTR 引脚上的请求有效、标志位 IF 为一。三个条件缺一不可——这就是 5.4 实录里"请求线明明有信号却没进服务程序"的判定学基础。条件满足后，处理器通过总线发出中断应答信号，把总线的发言权短暂交给中断控制器。

第二段：隐操作。 硬件在几十个时钟内自动完成一串动作，次序铁定：先把 IF 与单步标志清零（响应新中断的第一件事是关掉再被打断的门，防止现场没收拾完又被掀翻）；再把标志寄存器、断点段址 CS、断点偏移 IP 依次压栈——三样恰是"回到原地"的全部凭据；然后从数据总线取回控制器送来的类型码，查向量表得入口，控制流跳入服务程序。这段"隐操作"对程序员透明，却是整个机制的中枢。

第三段：现场保护与第四段：服务执行。 隐操作只保护了三样，服务程序自己用到的寄存器必须自己压栈保存——这是铁律，漏保一个寄存器，被中断的程序就会在返回后发现某个值莫名被改。服务程序的中段处理事务；若允许更急的中断插队，此刻可执行开中断指令把 IF 重新置位。收尾时向控制器发结束命令（办完销号，5.1 的案例已经演示过漏销号的后果），再弹出保存的寄存器。

第五段：返回。 中断返回指令依次弹回 IP、CS、标志寄存器——注意它与普通返回指令的区别：多弹一份标志，恢复的是被中断那一刻的 IF 状态。关中断是响应时硬件自动做的，恢复却要靠返回指令从栈里取，这一进一出严格对称，机制才闭环。

嵌套：中断里的插队规则

服务程序开了 IF 之后，更高优先级的请求就能插队进来，形成嵌套。栈是嵌套的账本：每深入一层，就多压一组断点与现场。

图 5-1：两级中断嵌套时的栈与控制流

嵌套有一条隐性纪律：服务时间越短越好，能不嵌就不嵌。每层嵌套多付一组压弹开销，多占一份栈空间；实时系统里常见的设计是"服务程序只做最必要的事，重活交给主循环"，把嵌套深度天然压在一两层。

案例展开：嵌套失控压塌了栈

背景：某仪表项目的显示刷新中断（低优先级）服务程序写得冗长，期间串口中断（高优先级）频繁插队，运行数小时后设备偶发死机，复位后无痕。操作：在调试器里冻结现场，检查栈指针——它指向了数据段的深处，栈底早已被击穿；回推栈的内容，发现大量重复的断点帧，是两层中断相互嵌套压出来的。结果：把显示刷新服务拆成"置标志位"与"主循环刷新"两半，服务时间从毫秒级压到几十微秒；串口插队次数骤减，栈深度稳定在安全线内，死机不再复现。解读：嵌套深度是服务时间的函数——高优先级中断插队的前提是低优先级服务"正好在跑"，服务越短，被插的机会越小。治嵌套失控，先治长服务。 变式：若业务决定了服务必须长，则应给服务期间到的次级请求排队（由控制器暂存申请），并按最坏情况放大栈容量——两种修法，对应两种实时策略。

把隐操作折成时间。八十年代标本上，七步隐操作合计几十个时钟，五兆赫兹下约十微秒量级；现代处理器的对应流程压缩到纳秒量级，但结构一步未省——关中断、存现场、取向量、进服务。把这个时间与 5.1 的三段式相加，就得到中断响应的完整账单；再把账单与外设的事件间隔并排，实时性的可行性判断就成了两次乘法。所有"这个中断接不接得住"的问题，答案都在这张对账单上。

隐操作的逐拍清单与一个经典误用

把隐操作写成台账，每一步都问一次"谁做的"：清 IF 与 TF——硬件；压标志寄存器——硬件；压断点段址——硬件；压断点偏移——硬件；从数据总线收类型码——硬件；查向量表算入口——硬件；跳转入服务程序——硬件。七步全部自动完成，这正是"隐"字的含义。服务程序的台账同样清晰：保存自己要动的寄存器——软件；必要时开中断允许嵌套——软件；处理事务——软件；发结束命令——软件；恢复寄存器——软件；返回——软件一条指令。

一个经典误用值得专门记录：服务程序结尾误用了普通子程序返回指令而不是中断返回指令。普通返回只弹回断点的两个字段，不弹标志寄存器——栈上多出一份没退场的旧标志，栈指针从此错位两个字节。症状极具迷惑性：中断本身一切正常，主程序却在返回后的某次调用里莫名取错参数。中断返回指令多弹的那一份标志，既是机制的对称性，也是栈平衡的记账员——谁替谁弹了什么，进出必须配平。

高频追问两则

问：服务程序里到底该不该开中断？ 看两件事：本服务要跑多久、有没有更高优先级的申请等不起。跑得久且有人等不起，就该在中段开中断放行插队；跑得短，全程关着更安全。判断标准不是"开中断是好习惯"，而是延迟预算——实时系统的每个决定都回到这笔账。

问：为什么响应新中断前硬件要先关中断？ 因为现场保护是多步操作，若保护到一半又被新中断掀翻，栈上会叠出错乱的现场，返回路径全部失真。先关门、再收拾、收拾完再开门——中断机制的这条纪律与多线程代码的临界区思想完全同构，硬件早就替你把锁设计好了。

本节要点回顾

• 三条件齐活才响应：指令边界、请求有效、IF 置位。
• 隐操作五连：关中断、压标志、压断点、取向量、跳入口，全由硬件包办。
• 服务程序两包办：保护自己的现场、结束发销号。
• 返回指令自带对称性：多弹一份标志，IF 恢复原样。
• 嵌套是特权不是常态：更高才可插队，深度与栈容量必须一起预算。

机制逐拍走完了，下一站看机制背后的权力机构——8259 与它的现代继任者如何管理八条以上的申请线。