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

Question

When trying to read from x86 input / output ports (in particular, Pentium), can the IN command insert commands while waiting for data, or will they always return immediately?

Answer 1

Short answer: Yes , in theory, an I / O device can cause the CPU to “block” a read / output ( in ) command.

However, I do not know of any memory or I / O devices that have actually stalled for any significant period of time, resulting in CPU blocking.

---

Long answer:

The in and out commands read / write I / O, which is almost identical to a typical memory bus cycle. The only difference is that the other signal (s) are approved to indicate I / O access and memory access.

Now it is getting pretty low level, and the details are becoming more complex with later processors. I refer to this presentation goes into details of the signal level of x86 bus cycles, starting with 8086/8088.

8086/8088 Read cycle from 1st wait state ^{https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf}

We see here that there is a READY signal that is validated by a memory or I / O device to indicate that it has submitted its data to the bus and is ready for the CPU to snap it. This pdf contains

x86 has a READY Input Line on the control bus

- READY Entry "Verified" during T3

- If READY is inactive (LOW), additional T3 states are added

- These additional T3 states are called Wait States.

Thus, it is possible with these older processors, at least, that the device can wait many cycles until the READY approved, causing the CPU to “block” the memory or I / O command.

I believe this is still relevant, at least through Pentium 4 , which has a DRDY# (Data Ready) contact, which "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 early systems, I believe that many system devices were connected directly to addresses / data / other lines and transferred directly from the CPU. Thus, some ordinary or ruddy device may “stop” in the bus cycle.

Now days, the architecture is very different. Modern x86 processors do not even have address and data contacts as such, but instead have links such as DMI and QPI that tell the northbridge / southbridge (or Platform Controller Hub ) to configure. These devices then forward memory / I / O requests to their respective devices. With this setting, I doubt that PCH will allow the output I / O reading to stop the processor request through the QPI channel.

Answer 2

As far as I know, there is only one “blocking” instruction in the x86 processor family: “HLT”.

"IN" and "OUT" (and their variants) are nothing more than read / write access to memory. Therefore (looking at the hardware) they behave exactly like the "MOV" instruction from / to memory - except that they access a different range of addresses.

There is one way to make the "IN" block: you can imagine some kind of hardware component that will stop the computer when it is accessed. When such a component uses an address with memory, then even the “MOV” instruction can block the CPU!

However, such a hardware component is more theoretical and, as far as I know, is absent on current computers.

Answer 3

My information is very old, but most processors that I know have some mechanism to synchronize slow hardware devices with a fast processor. Slow and fast here relative and slow usually means microseconds versus nanoseconds.

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

By the way, I'm not sure about x86, but on some architectures an IO device can actually stop the processor for an infinite amount of time.

Does this await blocking? I do not know, but these instructions can be slow, and the speed may depend on the hardware. In addition, IO instructions are not cacheable, and it is very slow.

For better reference, you should additionally familiarize yourself with the specifications of the PCI bus and the modern hardware specification of the processors.