Can the IN (as well as INS, INSB, etc.) instruction block in x86 assembly?

When trying to read from I/O ports on x86 (Pentium specifically), can the IN family of instructions block while waiting for data or will they always return immediately?

On the x86 family of processors there is - as far as I know - only one "blocking" instruction: "HLT".

"IN" and "OUT" (and their variants) are nothing but read/write accesses to memory. Therefore (looking at the hardware) they behave exactly like a "MOV" instruction from/to memory - with the exception that they access another address range.

There is one possibility to make "IN" block: You could imagine some hardware component that will stop the computer when it is accessed. When such a component uses a "memory mapped" address then even a "MOV" instruction would cause the CPU to block!

However such a hardware component is more theoretical and - as far as I know - not present in current computers.

My information is very old, but most processors I know have some mechanism of synchronization of the slow hardware devices with the fast CPU. Slow and fast here is relative and slow means usually microseconds vs nanoseconds.

So, when in/out instruction is executed, the CPU can wait a little until the IO device is ready with the information.

BTW, I am not sure about x86, but on some architectures, the IO device really can stop the CPU for infinite time.

Is this wait "blocking"? I don't know, but these instructions can be slow and the speed can depends on the hardware. Additionally, the IO instructions are not cacheable and this is very slow as well.

For better reference one has to read more on PCI bus specifications and modern processors hardware specification as well.

Short answer: **Yes**, in theory, an I/O device *could* cause the CPU to "block" on an I/O read (`in` instruction).

However, I'm not aware of any memory or I/O devices that actually stalled for any significant period of time, causing CPU execution to "block".

---

Long Answer:

The `in` and `out` instructions perform an I/O read/write, which is almost identical to a typical memory bus cycle. The only difference is that a different signal(s) is asserted to indicate I/O vs. memory access.

Now this gets pretty low-level, and the details get more complex with later CPUs. I'm referencing [this presentation][1] goes into signal-level detail about the x86 bus cycles, starting with the 8086/8088.

**8086/8088 Read Cycle with 1 Wait State**
![8086/8088 Read Cycle with 1 Wait State][2]
<sup>https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf</sup>


We see here that there is a `READY` signal, which is asserted by the memory or I/O device, to indicate that it has presented its data to the bus, and is *ready* for the CPU to latch it in. That PDF states

> x86 has a READY Input Line on Control Bus

> – READY Input “Checked” During T3

> – If READY is Inactive (LOW), Additional T3 States are Added

> – These Additional T3 States are Called “Wait States”

So it is possible, with these older CPUs at least, that a device could wait many cycles before asserting `READY`, causing the CPU to "block" on the memory or I/O instruction.

I believe this is still valid, at least through the [Pentium 4][3], which has a `DRDY#` (Data Ready) pin that `"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."`


---

Longer Answer:

With the early systems, I believe many of the system devices were connected directly to the address/data/other lines and communicated directly with the CPU. So some custom or rouge device could probably "stall" on a bus cycle.

Now days, the architecture is much different. Modern x86 processors don't even have "address" and "data" pins per se, but instead have links like [DMI][4] and [QPI][5], which communicate to a northbridge/southbridge (or [Platform Controller Hub][6]) setup. These devices then forward on the memory/IO requests to appropriate devices. With this setup, I doubt that the PCH would allow an outgoing I/O read to stall a processor request over the QPI link.


[1]:
[2]:

[3]:
[4]:

[To see links please register here]

[5]:

[To see links please register here]

[6]:

[To see links please register here]