OSDev.org

From the programmer's point of view, communicating with I/O devices is really simple and straightforward with a consistent, backward compatible interface. Usually, the way communication happens with the I/O devices is by issuing CPU instructions that write to CPU's I/O ports. Hardware device controllers have internal registers that controls them (Requesting stuff from th device, r/w stuff from/to the device ...etc.). Those internal registers, of each device controller, are mapped to the CPU's I/O ports so that writing and reading to CPU's I/O ports is actually writing and reading to the device's registers and thus controlling the device. That's an interesting way to make life easier on the programmer by abstracting all the horrible physical details and the underlying system's architecture.

However, we all know that there is more than this on the physical system level, I/O devices have different interfaces (IDE, SCSI, LPI ... etc) based on their nature and needs. And they are connected on different types of buses (AT, PCI, PCIe, IDE). CPUs gets connected by high speed, special purpose proprietary buses with the RAM. They connect on standardized high speed buses like PCIe with other high speed devices like Ethernet cards and Graphics cards and all gets linked through some kind of a north bridge that contains the PCI controller hub and other stuff. Low speed and legacy devices (Keyboards, IDE drives, BIOS ... etc) are bridged through a platform controller hub or a south bridge (Intel's terminology).

Now, the thing that i don't clearly see is how does the communication happen in real life with all those details and buses ? I mean how does writing some integer value into some CPU's I/O port by issuing a simple CPU instruction like

movb $PORT, %dh
outb %al, %dh

gets propagated through all the system's hardware components (Buses, Bridges, Controllers ... etc.) and eventually gets written to, let's say, the IDE's disk controller's commands register and thus commands the disk to perform some action (R/W a sector) ?

What puzzles me more is that the same port, the same instructions causes the same things to happen even after years of radical architectural changes (Changes in buses specifications, system architecture ... etc.) !! Does the chipset and the hardware manufacturer makes sure to forward the writes to their exact locations in hardwired manner ? For instance, an IDE command might be translated to a PCI request to traverse the PCI bus down to the south bridge than gets translated to something else until it reaches the IDE controller ?

I just want to understand how all this happens and how does the manufacturers always makes sure things are consistent and backward compatible whatever the underlying architecture looks like ?

By the way i am looking for some kind of a book or an article that explains that stuff in details, so a help in this regard will be much appreciated.

It can be a purely hardware solution or software-assisted. Look up SMM/SMI. A port access can trigger a special kind of interrupt transparent to the OS and in the interrupt handler the CPU can simulate the I/O device in a radically different way.

afr0ck wrote: Now, the thing that i don't clearly see is how does the communication happen in real life with all those details and buses ? I mean how does writing some integer value into some CPU's I/O port by issuing a simple CPU instruction like

movb $PORT, %dh
outb %al, %dh

gets propagated through all the system's hardware components (Buses, Bridges, Controllers ... etc.) and eventually gets written to, let's say, the IDE's disk controller's commands register and thus commands the disk to perform some action (R/W a sector) ?

North bridge and south bridge working in tandem. The classic architecture is, you have a CPU that is connected only to the north bridge (memory controller), which connects up to the RAM, maybe a high-speed bus like PCIe, and the south bridge (I/O controller). And the south bridge connects up to all other things. You output something on a port, that is a transaction that is sent to the north bridge, which propagates it further.

afr0ck wrote: What puzzles me more is that the same port, the same instructions causes the same things to happen even after years of radical architectural changes (Changes in buses specifications, system architecture ... etc.) !! Does the chipset and the hardware manufacturer makes sure to forward the writes to their exact locations in hardwired manner ? For instance, an IDE command might be translated to a PCI request to traverse the PCI bus down to the south bridge than gets translated to something else until it reaches the IDE controller ?

Simple: They just always kept the existing port assignments. Also, they integrated the same chips that were present in the IBM 5150 into the south bridge / PCH. Open up a 2019 gaming PC, and you'll find a PCH. Find its data sheet, and you'll find it contains the relevant parts of an Intel 8259, among other things.

There was a time when "legacy-free" PCs were all the rage. These would finally dispense with all the old stuff that has been superseded by now (no PIC, only APIC, no PIT, only HPET, etc.). Unfortunately, even these PCs would try to hold backwards compatibility, and thus emulate the hardware that is no longer present, with SMIs that would change the settings of the newer counterpart. No-one expects to have the APIC changed if they write to the PIC, but that is what happened here.

You could take a look at the PCI spec to understand how this works on a modern bus. Memory accesses (e.g. to a framebuffer of an external graphics card or MMIO) are translated to messages that are sent on PCI's wire protocol. The same thing happens for port I/O. Devices listen for messages to their own memory regions and respond accordingly.

It helps to remember that the CPU has a very limited interface/connection to the outside world. It can basically request a read or write on a memory bus, or request a read or write on the I/O bus.

Over time, the CPU "package" has grown, in the sense that a lot of components that used to be physically located on the motherboard are now located on the CPU package, to improve performance (shorter traces). So you can now think of the CPU "core" as the actual CPU, and all of the other stuff, like memory controllers and video adapters, as a sort of mini-motherboard that sits on top of the actual motherboard. This is what made the maker-board craze possible, because the external components needed to run a modern CPU are minimal. (power supply, networking, input controllers, storage, etc.)

So, as far as the CPU core (where your code is executed) is concerned, not much has changed over the years. Only the physical location and size of the other components have changed. The "success" of Intel over the past 40 years has been due in no small part to their strategy of maintaining backward compatibility. If they had not built their legacy on top of their 1970's era platform, there is little doubt that we wouldn't even remember the name Intel. There are plenty of companies that have tried to cut ties with their established platform, and were unable to survive the transition.