That may cause confusion. The term Memory mapped I/O generally refers to the method used my Motorola, not Intel. Apple built machines that used Memory mapped I/O .
the IBM PC uses memory mapped IO as well.
The I/O array does not cut into space in the Memory area.
I never said it did. In fact I'm not sure if you're talking about I/O ports, or I/O addresses, since it's rather vague. I'm not sure if it does anymore (things are probably different in protected mode and x64 Native mode ) Although it does "use" memory in Real Mode; the 384K of HMA memory above the DOS accessible 640K was addressable by even the original IBM PC; it was reserved however to perform memory mapped I/O with the various hardware devices, as well as map the various ROM codes into addressable memory space, so that they could, you know, be executed. Additionally, if what you say is true, I've witnessed magic when using the original PC [GW]BASIC[A] "POKE" instruction to write values to memory would light up pixels/characters on the display. I am curious how this mapping took place if there was no mapping. This was using POKE to poke memory addresses, not OUT to work with I/O Ports directly.
Today the memory doesn't stay "used"; the device driver locks an area of memory using appropriate kernel functions and communicates with the device using that memory, and then when it's finished communicating with it it unlocks it, which means the OS is free to use it for what it pleases. Bear in mind however that almost no Device nowadays really uses I/O addresses in this manner; generally the communication is handled by DMA transfers by the chipset, which manages all the hairy stuff. In fact I/O memory mapping like this is only done if you purposely force Programmed I/O on your devices; usually it's slower but if your hardware is finicky can be more reliable then DMA bus mastering.
I/O Ports are not necessarily I/O addresses, and I/O ports do not necessarily correspond directly to the electronic input into a chip or chipset.
From the same wikipedia article you quoted:
A final reason that memory-mapped I/O is preferred in x86-based architectures is that the instructions that perform port-based I/O are limited to one or two registers: EAX, AX, and AL are the only registers that data can be moved in to or out of, and either a byte-sized immediate value in the instruction or a value in register DX determines which port is the source or destination port of the transfer[1][2]. Since any general purpose register can send or receive data to or from memory and memory-mapped I/O, memory-mapped I/O uses less instructions and can run faster than port I/O. AMD did not extend the port I/O instructions when defining the x86-64 architecture to support 64-bit ports, so 64-bit transfers cannot be performed using port I/O[3].
and
Memory-mapped I/O is the cause of memory barriers in older generations of computers – the 640 KiB barrier is due to the IBM PC placing the Upper Memory Area in the 640–1024 KiB range (of its 20-bit memory addressing), while the 3 GB barrier is due to similar memory-mapping in 32-bit architectures in the 3–4 GB range.
If they didn't do memory mapped I/O, I'd like to know how they caused these observable barriers and how they would be preferable. thx.
also:
http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-mapPhysical memory addresses are also used for communication with assorted devices on the motherboard (this communication is called memory-mapped I/O). These devices include video cards, most PCI cards (say, a scanner or SCSI card), and also the flash memory that stores the BIOS.
BC, Please read the x86 instruction set from cover to cover.
haha, yeah,
I should read it. k.