Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Short answer: <strong>Yes</strong>, in theory, an I/O device <em>could</em> cause the CPU to "block" on an I/O read (<code>in</code> instruction).</p> <p>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".</p> <hr> <p>Long Answer:</p> <p>The <code>in</code> and <code>out</code> 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.</p> <p>Now this gets pretty low-level, and the details get more complex with later CPUs. I'm referencing <a href="https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf" rel="nofollow noreferrer">this presentation</a> goes into signal-level detail about the x86 bus cycles, starting with the 8086/8088.</p> <p><strong>8086/8088 Read Cycle with 1 Wait State</strong> <img src="https://i.stack.imgur.com/hroeR.png" alt="8086/8088 Read Cycle with 1 Wait State"> <sup><a href="https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf" rel="nofollow noreferrer">https://web.archive.org/web/20130319052544/http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf</a></sup></p> <p>We see here that there is a <code>READY</code> signal, which is asserted by the memory or I/O device, to indicate that it has presented its data to the bus, and is <em>ready</em> for the CPU to latch it in. That PDF states</p> <blockquote> <p>x86 has a READY Input Line on Control Bus</p> <p>– READY Input “Checked” During T3</p> <p>– If READY is Inactive (LOW), Additional T3 States are Added</p> <p>– These Additional T3 States are Called “Wait States”</p> </blockquote> <p>So it is possible, with these older CPUs at least, that a device could wait many cycles before asserting <code>READY</code>, causing the CPU to "block" on the memory or I/O instruction.</p> <p>I believe this is still valid, at least through the <a href="http://download.intel.com/design/Pentium4/datashts/30056103.pdf" rel="nofollow noreferrer">Pentium 4</a>, which has a <code>DRDY#</code> (Data Ready) pin that <code>"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."</code></p> <hr> <p>Longer Answer:</p> <p>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.</p> <p>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 <a href="http://en.wikipedia.org/wiki/Direct_Media_Interface" rel="nofollow noreferrer">DMI</a> and <a href="http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect" rel="nofollow noreferrer">QPI</a>, which communicate to a northbridge/southbridge (or <a href="http://en.wikipedia.org/wiki/Platform_Controller_Hub" rel="nofollow noreferrer">Platform Controller Hub</a>) 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.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload