X86 管道中的软件中断会发生什么情况？

读完这篇文章：

关于软件中断会发生什么情况的信息不多，但我们确实了解到以下几点：

相反，异常（如页面错误）会标记受影响的指令。当该指令即将提交时，将刷新异常之后的所有后续指令，并重定向指令获取

我想知道管道中的软件中断（int0xx）会发生什么情况，首先，何时检测到它们？它们可能是在灭绝前阶段被发现的吗？在指令队列中？在解码阶段？或者他们到达后端并立即完成（不要进入预订站），然后依次退出，退出阶段发现这是一条INT指令（似乎是浪费）

假设它是在预编码时提取的，必须有一种方法向IFU发送停止提取指令的信号，或者确实是对其进行时钟/功率选通，或者如果它是在指令队列中提取的，则有一种方法在它进入队列之前刷新指令。然后必须有一种向某种逻辑（“控制单元”）发送信号的方式，例如，为软件中断生成UOP（索引到IDT，检查DPL>=CPL>=segment RPL，等等），这是一个天真的建议，但如果有人更了解这个过程，那就太好了

---

我还想知道当这个过程受到干扰时，它是如何处理的，即硬件中断发生（请记住陷阱不清楚是否在EFLAGS中），现在必须开始一个全新的中断处理和uop生成过程，之后它将如何回到处理软件中断的状态。

Andy@Krazy Glew的那句话是关于在执行“正常”指令时发现的同步异常，如

mov eax，[rdi]

如果发现rdi指向未映射的页面，则提高#PF。1您希望不会出现故障，因此，您可以将任何操作推迟到退休，以防它处于分支预测失误或早期异常的阴影下

---

但是，是的，他的回答没有详细说明管道如何优化同步

int

trap指令，我们知道这些指令在解码时总是会导致异常。陷阱指令在整个指令组合中也非常罕见，因此为它们进行优化并不会为您节省很多能量；做容易的事才值得

正如Andy所说，当前的CPU没有重命名特权级别，因此无法推测到中断/异常处理程序，因此在看到

int

或

syscall

后暂停获取/解码绝对是明智的。我只想编写

int

或“trap指令”，但

syscall

/

sysenter

/

sysret

/

iret

和其他更改权限的“分支”指令也是如此。以及类似的

int3

（

0xcc

）和

int1

（

0xf1

）。溢出

到
的条件陷阱很有趣；对于无陷阱情况下的非可怕性能，可能假定不存在陷阱。（当然还有
vmcall
和用于VMX扩展的东西，可能还有SGX
EENTER
，可能还有其他东西。但就暂停管道而言，我猜所有陷阱指令都是相同的，除了条件
到
）


我假设，就像
lfence
一样，CPU不会推测陷阱指令的过去。你是对的，那些UOP在管道中没有意义，因为
int
之后的任何东西都肯定会被刷新

IDK，如果在
int
指令在后端变为非推测性之前，从IVT（实模式中断向量表）或IDT（中断描述符表）获取
int
处理程序的地址。可能地（一些陷阱指令，如
syscall
，使用MSR设置处理程序地址，因此从那里开始代码提取可能会有用，特别是如果它提前触发L1i未命中。这必须与分支未命中后在错误路径上看到
int
和其他陷阱指令的可能性进行权衡。）

误判命中陷阱指令的情况可能非常罕见，如果前端足够聪明，能够处理所有这些，那么只要前端看到陷阱指令，就应该从IDT开始加载或预取
syscall
入口点。但可能不是。将这些花哨的东西留给微代码来限制前端的复杂性是有意义的。即使在
syscall
繁重的工作负载中，陷阱也很少见。将工作分批交给用户/内核是一件好事，因为廉价的
syscall
很难实现后幽灵


因此，最晚会在发出/重命名（已经知道如何暂停（部分）序列化指令）中检测到陷阱。，并且在退出
int
并执行异常之前，不会向无序后端分配更多UOP

但在解码中检测到它似乎是有可能的，而不是在一条指令出现异常后进一步解码。（我们不知道下一步从哪里获取。）解码器阶段确实知道如何暂停，例如非法指令陷阱

假设它是在predecode提取的

这可能不实用，在完全解码之前，您不知道它是一个
int
。预解码只是英特尔CPU上的指令长度查找。我假设
int
和
syscall
的操作码只是具有相同长度的许多操作码中的两个

在硬件中构建更深入的陷阱指令搜索将花费比预解码更高的功耗。（记住，陷阱非常罕见，而且