Do the following two references give different claims on the relations between IO ports and registers in a device controller? What are their relations actually?

Does the following quote from https://cs.nyu.edu/courses/fall10/V22.0436-001/lecture24.html mean that in a device controller, there is exactly one IO port for each register, and there is exactly one register for each IO port?

Each I/O device is connected to the I/O bus through a controller. A simple controller will have at least 3 addresses (ports) on the bus, each corresponding to a register in the controller

  • a data register (either readable or writable, depending on whether it is an input or output device)
  • a control register (writable, for controlling device operation)
  • a status register (readable, for determining device status -- in particular, whether it is ready to receive or provide data)

More complex devices (e.g., disks) will have multiple control and status registers

Does the following quote from Operating System Concepts mean that in a device controller, a IO port has four registers?

An I/O port typically consists of four registers, called the status, control, data-in, and data-out registers.

• The data-in register is read by the host to get input.

• The data-out register is written by the host to send output.

• The status register contains bits that can be read by the host.

• The control register. ...


closed as off-topic by DavidPostill Oct 1 '18 at 19:30

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking product, service, or learning material recommendations are off-topic because they become outdated quickly and attract opinion-based answers. Instead, describe your situation and the specific problem you're trying to solve. Share your research. Here are a few suggestions on how to properly ask this type of question." – DavidPostill
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I suggest you look through some datasheets of real hardware to get a better idea what can happen. While this correctly describes the basic idea, real-world chips are weird, and you won't believe the range of ideas that hardware designers have ... – dirkt Oct 1 '18 at 18:43
  • Tim, please read the question close text more closely. This category of question is off-topic here on SU. – I say Reinstate Monica Oct 1 '18 at 23:59
  • @TwistyImpersonator I am not asking for "product, service, or learning material recommendations". My question is valid. (I forgot "not" in my previous comment) – Tim Oct 2 '18 at 0:07
  • @Tim LOL...ok I wondered if that might have been the case. – I say Reinstate Monica Oct 2 '18 at 0:17
  • 1
    Well, I didn't VTC based on your comment, but rather your question. In its current form can't justify a reopen vote. Your question might do better if you edit it to describe the actual problem you're trying to solve. – I say Reinstate Monica Oct 2 '18 at 0:24

What you describe in your post is a "typical" scenario, especially if I/O is on a different bus than the CPU (PCI/PCI is a good example) or you are talking to a controller rather than the actual I/O device. Reality is much more messier of course.

Hardware can be designed to react in any way the hardware designer wants to read/write requests from the CPU.

For example, it's possible to:

  • Make it so mere access (read or write) to an I/O address causes the device to do something.

  • Make it so reads and writes to the same I/O address actually access different registers or functions on the device.

  • Simple devices may not need a data, control, and status register. The PC parallel port is an example. It's controlled by a single byte in the I/O address space.

Of course, any such devices would be directly addressable by the CPU and not "behind" a controller. Parallel port being an old-school ISA device. Though these days it's actually the LPC bus, but LPC is designed to work like ISA.

The above was far more common in the pre-PC era, and is I believe common on non-x86 platforms like ARM and MIPS.

Complex controllers (most of them) will need an additional mechanism for you to specify which device connected to the controller you want to talk to. I2C is like this.


IP is typically designed as modules with clearly defined boundaries... often they sit in the address space of the processor core. It would be possible to develop an I/O block with either a single Input or Output pin, that has a single bit of a register wired up to either read the input value or set the output value... but that's not useful and quite wasteful on the address space.

Instead, modules are designed to be more "featureful" and thus in some cases, more parallel - the AVR I/O modules have 8 input/output pins, while the STM32 I/O module has 16 pins. The AVR provides basic I/O functionality, while the STM32 has slew rate control, and alternate functions that can be mapped onto the drivers provided by the I/O pins.

Consider the I/O ports of the following:


avr i/o registers


stm32 i/o registers

Does the following quote [...] mean that in a device controller, there is exactly one IO port for each register, and there is exactly one register for each IO port?

I'd say "no" - it's implying that there will be at least some form of data, control and status interface for an I/O module.

Remember that a lot of educational material presents a model that is easy to understand, before invalidating it an presenting the caveats and technical complexity that really exists.

Does the following quote from Operating System Concepts mean that in a device controller, a IO port has four registers?

Again, I'd say "no"... It's giving a "typical" / "base" expectation of what something may consist of.

Not the answer you're looking for? Browse other questions tagged or ask your own question.