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.