为什么我们需要内存映射 IO？根据我在 CS 课上学到的知识，MMIO 抽象出控制设备的特定指令。但是，如果设备的控制寄存器（以及其地址空间部分中的每个内存单元）取决于设备的品牌和型号，那么在抽象方面会获得什么？
【问题讨论】：
标签： memory operating-system hardware
每个设备都有某种内部寄存器，软件（设备驱动程序）使用这些寄存器来控制设备的状态、要求设备执行操作并确定状态。
软件（设备驱动程序）可以通过两种主要方式访问设备的内部寄存器 - 将这些寄存器映射到 CPU 物理地址空间（与将内存映射到 CPU 物理地址空间的方式相同）；并通过提供专用机制（例如 80x86 上的 IO 端口）。
了解优势/劣势；最好考虑 CPU/s 和内存之间通信的性质。这种通信需要非常快，因为一切都依赖于它；并且（对于电子产品）“快速”往往意味着简单，总线长度短（由于电容和电阻等因素）和负载最少（因为每个负载都会增加驱动总线所需的电流，这意味着要处理更大的晶体管更高的电流，这意味着晶体管切换所需的时间更长）。当然，还有很多技巧可以让它更快，从缓存（可能还有缓存一致性）、预取和推测执行开始，以使 CPU 在等待数据时保持忙碌。
通过提供专用机制（例如 80x86 上的 IO 端口），一切看起来都不错；因为您将高速内存总线和所有（慢得多）的东西分开。
如果我们在性能最关键的数据路径（CPU 和 RAM 之间）的中间打上一个大杂烩，以便软件（设备驱动程序）可以使用内存映射 IO 访问设备的内部寄存器，该怎么办？天啊……
首先，您将研究缓存的一些主要复杂性（至少，以某种方式说“这些区域/s 应该被缓存，而这些区域/s 不应该被缓存”以及所有逻辑找出哪些访问被/没有被缓存，以及它增加的延迟）；加上 CPU 本身的更多主要复杂性（可以/应该尝试预取吗？它可以/应该推测性地执行读/写吗？）；加上更慢（负载更多）和/或更昂贵的总线来处理“谁知道可能插入什么设备”，可能会带来一些额外的痛苦（等待状态等）来处理比内存慢得多的设备。这听起来像是一个非常糟糕的主意。
然而，事实证明，很多设备都可以从直接访问内存总线中受益（使用总线主控/DMA 在设备和 RAM 之间直接传输数据；而不是内存映射 IO），所以你无论如何，大多数人最终都想要那辆较慢的巴士，而您最终也想处理所有其他复杂问题。
如果您查看历史记录（至少对于 80x86）；您会发现从“简单，主要使用 IO 端口”逐渐转变为“极其复杂，主要使用内存映射 IO”。
为什么我们需要内存映射 IO？
不，这不是绝对必要的（但如果您愿意接受性能/复杂性的后果，那就更好了）。
【讨论】：
从根本上说，要使 CPU 能够执行 IO，它需要一种向设备读取和写入数据的方法。有很多方法可以做到这一点，例如专用 CPU 指令，如 x86 上的 IN/OUT。 MMIO 是另一种已被证明在简化硬件设计方面很受欢迎的解决方案。
在典型的 CPU 上，所有内核都将连接到一个公共总线，该总线允许内核读取/写入主内存，也许还有共享缓存。然而，总线对于数据的来源、目的地和内容是不可知的。因此，总线上的传输可以转到不同的内存控制器、不同的内核、缓存等。因此，硬件设计人员可以简单地将 IO 设备连接到该总线，最终通过与 RAM 相同的机制访问这些设备。这有一些优点：
大多数这些优势都被软件所掩盖，因此我认为 MMIO 有利于硬件设计人员。
【讨论】：