可以在 x86 汇编中使用 IN（以及 INS、INSB 等）指令块吗？

Question

当尝试从 x86（特别是 Pentium）上的 I/O 端口读取数据时，IN 系列指令会在等待数据时阻塞还是总是立即返回？

Answer 1

简短回答：是的，理论上，I/O 设备可能导致 CPU 在读取 I/O 时“阻塞”（in 指令） .

但是，我不知道有任何内存或 I/O 设备实际上停滞了很长时间，从而导致 CPU 执行“阻塞”。

---

长答案：

in 和 out 指令执行 I/O 读/写，这几乎与典型的内存总线周期相同。唯一的区别是不同的信号被断言来指示 I/O 与内存访问。

现在这变得相当低级，并且随着后来的 CPU，细节变得更加复杂。我引用 this presentation 详细介绍了 x86 总线周期的信号级细节，从 8086/8088 开始。

具有 1 个等待状态的 8086/8088 读取周期 ^{https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf}

我们在这里看到有一个READY 信号，它由内存或 I/O 设备断言，表示它已将其数据提交给总线，并且准备好 CPU 将其锁定。该 PDF 状态

x86 在控制总线上有一条 READY 输入线

– T3 期间 READY 输入“已检查”

– 如果 READY 处于非活动状态 (LOW)，则添加其他 T3 状态

– 这些额外的 T3 状态称为“等待状态”

因此，至少对于这些较旧的 CPU，设备可能会在断言 READY 之前等待多个周期，从而导致 CPU 在内存或 I/O 指令上“阻塞”。

我相信这仍然有效，至少通过Pentium 4，它有一个DRDY#（数据就绪）引脚"is asserted by the data driver on each data transfer, indicating valid data on the data bus. In a multi-common clock data transfer, DRDY# may be de-asserted to insert idle clocks."

---

更长的答案：

对于早期的系统，我相信许多系统设备直接连接到地址/数据/其他线路，并直接与 CPU 通信。因此，一些定制或胭脂设备可能会在公共汽车循环中“停止”。

如今，架构已大不相同。现代 x86 处理器本身甚至没有“地址”和“数据”引脚，而是具有像 DMI 和 QPI 这样的链接，它们与北桥/南桥（或 Platform Controller Hub）设置进行通信。然后这些设备将内存/IO 请求转发到适当的设备。通过这种设置，我怀疑 PCH 是否会允许传出 I/O 读取来停止 QPI 链路上的处理器请求。

Answer 2

在 x86 系列处理器上，据我所知，只有一条“阻塞”指令：“HLT”。

“IN”和“OUT”（及其变体）只不过是对内存的读/写访问。因此（查看硬件）它们的行为与从/到内存的“MOV”指令完全一样 - 除了它们访问另一个地址范围之外。

有一种可能会阻止“IN”：您可以想象某些硬件组件会在访问计算机时停止计算机。当这样的组件使用“内存映射”地址时，即使是“MOV”指令也会导致 CPU 阻塞！

但是，这样的硬件组件更具理论性，而且据我所知，目前的计算机中不存在。

Answer 3

我的信息已经很老了，但是我知道的大多数处理器都有一些将慢速硬件设备与快速 CPU 同步的机制。这里的慢和快是相对的，慢意味着通常是微秒与纳秒。

因此，当执行 in/out 指令时，CPU 可以稍等片刻，直到 IO 设备准备好信息。

顺便说一句，我不确定 x86，但在某些架构上，IO 设备确实可以无限期停止 CPU。

这是等待“阻塞”吗？我不知道，但这些指令可能很慢，速度可能取决于硬件。此外，IO 指令不可缓存，而且速度也很慢。

为了获得更好的参考，还必须阅读有关 PCI 总线规范和现代处理器硬件规范的更多信息。