Talk:Programmed input–output

"Programmed I/O" is a generic term
Programmed I/O is also a generic term - if no one else wants to, I'll write up something about this in the next couple of days.. --131.111.203.154 16:52, 24 May 2005 (UTC)

CompactFlash
There should be more information on CompactFlash, perhaps on its own article. --Bookinvestor 16:58, 31 May 2007 (UTC)


 * So what's missing from the CompactFlash article? Guy Harris 17:48, 31 May 2007 (UTC)


 * Wow, my bad. I searched for it, but didn't get any results. Probably I mistyped it or something. Thank you for your help. --Bookinvestor 21:18, 31 May 2007 (UTC)

I think I know what he is talking about. He probably talking about there should be some explanation how PIO via a CompactFlash works. Like in "STEC MACH4. series SSD. I was wondering on that part too, but I totally no clue how it works.

By the way I think you guys should also look at the "DIY Century Compact Flash to SATA adapter. (its CompactFlash on SSD) via some unknown interface, this might help improve PIO on CompactFlash I guess. I haven't check the Technical Documentaiton or any White Papers yet, just so you know

--Ramu50 (talk) 04:40, 1 June 2008 (UTC)

Serious problems
Programmed I/O is PRIMARILY a generic term. Its association with ATA devices is incidental. Article should be rewritten accordingly. Jeh 18:54, 1 November 2007 (UTC)


 * Thank you for your suggestion. When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the  link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills.  New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to).


 * I attempted to add a few words to separate the generic concept of "programmed input/output" from the ATA-specific information.
 * --68.0.124.33 (talk) 13:39, 11 April 2008 (UTC)

Agreed. This article is just about 100% wrong. It's like looking up dog and finding a description of a Pekinese, as if that was the only - or even typical - dog. First, it's programmable I/O, not "programmed I/O", and it refers to controlling peripheral devices using the processors non-dedicated (hence programmable) I/O pins. For example, a reset pin. It's use in the old ATA interface is incidental, not definitive. — Preceding unsigned comment added by 217.44.103.164 (talk) 17:34, 31 March 2012 (UTC)

Potential Citations

 * Would http://www.t13.org/ be a reasonable source? It lists current and expired standards published by T13, a group created by ANSI to oversee ATA standards. (september 21, 2010) —Preceding unsigned comment added by 137.28.109.126 (talk) 16:46, 21 September 2010 (UTC)

Port-Mapped I/O (PMIO) vs. Programmed input–output (PIO)
Port-Mapped I/O is referred to this article. But is Port-Mapped I/O and Programmed input–output really the same? If so, why do they have different names? --84.158.122.178 (talk) 20:18, 9 January 2022 (UTC)
 * Port-mapped I/O is one way of performing programmed I/O; memory-mapped I/O is another. To quote the article:
 * "The term can refer to either memory-mapped I/O (MMIO) or port-mapped I/O (PMIO). PMIO refers to transfers using a special address space outside of normal memory, usually accessed with dedicated instructions, such as IN and OUT in x86 architectures. MMIO refers to transfers to I/O devices that are mapped into the normal address space available to the program. PMIO was very useful for early microprocessors with small address spaces, since the valuable resource was not consumed by the I/O devices."


 * So I/O performed by special instructions that use special I/O addresses to refer to device registers is port-mapped I/O, and I/O performed by ordinary memory reference instructions such as load and store, with the operand addresses referred to by those instructions being in a special region of "memory" addresses containing device registers, is memory-mapped I/O. If the special instructions, or memory reference instructions, transfer data between the device and processor registers or processor memory, that's programmed I/O, regardless of which instructions are used. Guy Harris (talk) 23:16, 15 August 2022 (UTC)

So what is "programmed input-output?
I've found at least two texts, and one paper, that speak of at least three types of I/O:


 * "programmed I/O", in which the CPU busy-waits until data is available to transfer on input or the device is ready to accept data on output, and then transfers the data;
 * "interrupt-driven I/O", in which data transfers are done in response to interrupts, so that, instead of busy-waiting for the device to be ready to provide or accept data, the device interrupts the CPU when it's ready, and the code that responds to the interrupt transfers the data;
 * "DMA"/"channel" I/O, in which the device, or a "channel" connected to the device, can transfer data directly to or from memory without the CPU being involved. An interrupt is usually delivered when the transfer completes.

(Note, however, that for "DMA"/"channel" I/O, CPU circuitry may be involved, even if CPU instructions aren't involved in the data transfer process. For example, data channels on the IBM System/360 Model 40 are implemented with CPU data paths and microcode; byte-mode data transfers on the multiplexor channel are serviced by the microcode in a microprogram interrupt service routine that transfers a byte and then returns to the main microcode flow, burst-mode data transfers on the multiplexor channel are serviced by the microcode in a microprogram interrupt service routine that transfers a burst of data in a loop and then returns to the main microcode flow, and data transfers on the selector channel are serviced in a microprogram interrupt service routine that transfers one or two bytes and returns to the main microcode flow.  From the operating system's point of view, the data transfer doesn't require its attention for every byte transferred, so it doesn't appear as if it's "programmed I/O" or "interrupt-driven I/O", but the CPU is unable to execute instructions while data is being transferred, as it is, at the microcode level, interrupt-driven I/O. Other lower-end System/360 models are similar; larger models have separate data channel hardware, allowing the CPU to execute instructions while data transfers are in progress.

For another example, on the IBM 1130, "cycle-stealing" for DMA-style transfers to and from memory halt the CPU while a character is being transferred, invisibly to the CPU, so, while the operating system doesn't need to be involved for every byte transferred, the CPU is unable to execute instructions while data is being transferred. The same applies to the high speed channel on the PDP-1. )

The "programmed I/O' described in this article applies to the first two types of I/O, in that data transfer can involve either a loop of

while (device is busy) ;   transfer data to or from the device with an instruction sequence;

or can involve an interrupt service routine that does the transfer with an instruction sequence.

I'm not sure what to do about "programmed I/O" vs. "interrupt-driven I/O". Should those have separate pages, with this page describing only the non-interrupt-driven (busy-wait) I/O, or should this page cover both?

ATA I/O does not require "programmed I/O" in either sense, and "programmed I/O" in either sense doesn't require an ATA bus. As such, the right thing to do might be to put the ATA-specific information here in another page. The WDMA (computer) page covers the "Word DMA" ATA interface, and the UDMA page covers the "Ultra DMA" ATA interface; perhaps there should be a separate page - "PIO (ATA)"? - for the PIO ATA interface, with this page having a hatnote pointing to that page for people who came here looking for ATA PIO rather than for "programmed I/O" in general. Guy Harris (talk) 10:11, 16 August 2022 (UTC)
 * On the other hand, the Interface and Installation Manual for the PDP-7 speaks of "programmed data transfers" that can either be done in mainline code or in an interrupt routine, so that term includes both "programmed I/O' and "interrupt-driven I/O" in the senses used by the books mentioned above.
 * So my inclination would be to have this page cover both non-interrupt-driven and interrupt-driven I/O where a sequence of one or more CPU instructions is used to transfer data to or from peripheral devices, and to make a distinction between those two way of using the instructions (doing the data transfer in-line, and stalling the program until the entire transfer is complete, versus getting an interrupt when data can be transferred and doing the data transfer in an interrupt service routine). Note that some transfers of control information to or from peripheral devices, such as telling a disk to seek to a given track and start reading or writing at a given sector on that track, might be done in-line even with interrupt-driven I/O. Guy Harris (talk) 07:07, 19 August 2022 (UTC)