Talk:Memory-mapped I/O and port-mapped I/O

Cumbersome?

The article presently contains the following Bull crap:

With the popularisation of higher-level programming languages such as C and Lisp, which do not support generation of the special port-mapped I/O instructions without incompatible and proprietary extensions, port-mapped I/O has become remarkably cumbersome to use.

This is horsepucky. C needs no extensions to do memory-mapped I/O, it simply requires that you understand how your compiler sizes and arranges the various quantities such as char, short, int, and long and how your run-time environment maps virtual memory into the physical address space. (Well, I suppose if you need 16-bit I/O bus accesses and your machine considers a "short" to be 32 bits, you'll need some help, but this is fortunately rare in real-world compilers.)

I've written C-language device drivers for four different platforms (Unix, OpenVMS, VxWorks, and raw iron 8051) so I'm pretty confident that I know of what I speak, but I'll certainly entertain dissenting opinions before editing this blatant POV out of the article. And I can't speak for Lisp so perhaps someone else can opine on that topic.

Atlant 16:28, 17 July 2005 (UTC)

I think Atlant misread the paragraph. It says C unt× doesn't directly support port-mapped I/O, not that it doesn't support memory-mapped I/O. But any code that has to control I/O ports directly is inherently unportable anyway, so the paragraph still doesn't make any sense. I removed it. Gazpacho 04:16, 6 November 2005 (UTC)

"I/O port" should not redirect to this article. An I/O port is an electrical connection and the circuitry that controls it, and is a completely separate topic from how a processor provides access to the port. Port-mapped I/O should also be moved to a separate article. I'll put this on my watchlist and get back to it soon. Gazpacho 04:08, 6 November 2005 (UTC)

"Memory map" also redirects here, even though the article only discusses them in the context of I/O. MFNickster 21:28, 11 November 2005 (UTC)

Indeed it does. I wrote an article at memory map, then someone merged it (or asked me to merge it, I forget) into this article. Admittedly it did cover quite a bit of common ground. Maybe it's this article's title that needs a rethink? Graham 02:19, 12 November 2005 (UTC)

Too bad they didn't redirect Memory mapping to here -- now there's a duplicate article there, too. Ewlyahoocom

16:46, 4 April 2006 (UTC)

I think it is beter to have them seperate as too much of info would be cramed in one single topic

Placement of ROM in the example

As I understand it, in common architectures, ROM needs to be at $0000-$00FF for some 8-bit microprocessors and $FF00-$FFFF for others to allow the processor to see the reset vector. I'll swap the addresses of I/O and ROM for the example. --Damian Yerrick (talk | stalk) 03:46, 28 January 2007 (UTC)

Requested move

Definately a bad title, but great content. I like the way this articles attempts to compare two distincts architectural choices. This is the way, that more articles should choose.

Some propositions, off the top of my head: I/O mechanism or I/O device addressing or I/O mapping. Sources needed.

Off-topic WP:OR remark: Also, come to think of it, memory-mapped I/O formally re-defines primary storage (aka main memory) in a very interesting way. Traditionally, primary storage is defined as the one that is directly addressable via CPU. What if... What if there are some registers in a sound card? Do they become my primary storage, too? Obviously, to a program they cannot be easily distinguished from memory locations. To go further... What if I would make a hard drive with entire capacity linearly memory-mapped? The idea of file system suddenly becomes somewhat less useful, since I have uniform pointers-to-RAM and pointers-to-disk now, doesn't it?

--Kubanczyk 00:36, 1 November 2007 (UTC)

What if I would make a hard drive with entire capacity linearly memory-mapped? That's pretty easy to do with virtual memory and paging. You can directly memory map the entire hard drive, from one end to the other, into one large consecutive block of virtual memory. (I'm assuming you have 32 bit pointers and a hard drive less than 4 GiB, or you have 64 bit pointers and a hard drive less than 16 EiB, or you have 128 bit pointers and you avoid boiling the oceans.) You may be interested in some discussion on the original wiki: WikiWikiWeb: FileSystemAlternatives. --68.0.124.33 (talk) 03:45, 25 October 2008 (UTC)

Some Questions

"In x86 architecture, an input/output base address is a base address used for an I/O port."

Does that mean that those addresses that you used to set by hand (0x220 for Sound Blasters for example) are port I/O addresses and not memory-mapped I/O? How does one determine which type of I/O is used? Is it determined by the hardware designer? Can both be used at the same time by the same device to access the same registers? Also, since 32-bit x86 processors have 4GB of address space, does using memory-mapping and 4GB of RAM make some of the RAM inaccessible? Is video RAM memory-mapped? If so, is it also incompatible with 4GB of physical RAM on 32-bit CPUs? —Preceding unsigned comment added by Totsugeki (talk • contribs) 21:04, 4 February 2008 (UTC)

I stumbled upon an answer to my second set of questions in the conventional memory article, in case anyone else is interested.Totsugeki (talk) 13:40, 23 March 2008 (UTC)

Interrupts

It is stated that an interrupt can only have the values 0 and 1. What about MSI(-X)? —Preceding unsigned comment added by 72.82.252.208 (talk) 03:42, 24 November 2008 (UTC)

Split

Please split this article between memory-mapped and port-mapped IO.

Or change the title to reflect both IO methods? 104.228.101.152 (talk) 00:43, 21 March 2020 (UTC)

Chipset

3, 2023, 01:09 - «Memory-mapped and port-mapped I/O predate chipsets; the PDP-11] had memory-mapped I/O back when various PDP-11s were made out of, for example, 7400-series integrated circuits looking at the 11/20 drawings, it looks as if it was made out of 74xx chips).»

@Guy Harris: Well the term "chipset" is platform-agnostic and means a set of Integrated circuits or devices, not a single IC or whater. The point is that Memory mapped I/O addresses are hardwired by a manufacturer of the computer. This should be said explicitly.

AXONOV (talk) ⚑ 20:00, 3 June 2023 (UTC)

@Alexander Davronov: Well the term "chipset" is platform-agnostic Citation needed on that claim. The chipset page says, in its first paragraph:

In a computer system, a chipset is a set of electronic components on one or more ULSI integrated circuits known as a "Data Flow Management System" that manages the data flow between the processor, memory and peripherals. It is usually found on the motherboard of computers. Chipsets are usually designed to work with a specific family of microprocessors. Because it controls communications between the processor and external devices, the chipset plays a crucial role in determining system performance.

The PDP-11/20 had no ULSI integrated circuits; it was a mix of SSI and MSI. The entire CPU, including the data path to the Unibus, was a set of chips. It may have been simple enough to have a motherboard rather than being on a set of multiple circuit boards, but there was no notion of a "chipset" in the PC sense.

The point is that Memory mapped I/O addresses are hardwired by a manufacturer of the computer. On the PDP-11, the architecture only defines the range of memory-mapped I/O addresses. The address of a particular device is specified by the device manufacturer; some devices may have had jumpers to allow the address to be set so as to avoid collisions.

And as for more modern buses, PCI devices don't have hardwired addresses, that's set up at configuration time either by system firmware or the OS. The range of memory or port addresses used for PCI may be specified by the CPU or other hardware, but individual device addresses aren't. Guy Harris (talk) 20:51, 3 June 2023 (UTC)

... And as for more modern buses, PCI devices don't have hardwired addresses, ... Well PCI Express configuration ranges are fixed. AXONOV (talk) ⚑ 21:41, 3 June 2023 (UTC)

Ranges, not addresses. And it's configuration ranges; if you have a mechanism to look up information about things by name or address, you can't use that mechanism to find the mechanism, so there needs to be some sort of fixed "root" from which to find other stuff. Memory and I/O addresses for devices, however, aren't fixed. Guy Harris (talk) 22:32, 3 June 2023 (UTC)

On many platforms ranges of RAM addresses for I/O ARE fixed and hardcoded and memory map (memory layout) IS predefined. This is true for many SOCs as well. In the context of PC arch, the PCIe map is configured via PCIe controller register to map into BIOS or OS-specified address ranges to be occupied by PCIe devices during runtime (usually in I/O range of the RAM space). Entire layout of the memory (I/O and General Memory address ranges) is always pre-defined by specific CPU/MCU/MPU arch and design.

This is especially evident on x86 systems: the Flash or EPROM I/O address range that contains BIOS always starts at 0xFFFFFFF0 for the first instruction to be executed upon system reset.

See sources and datasheets, .e.g:

• Modern Embedded Computing, 2012, pp. 44.
• Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1, pp. 335 (Chapter 10.10)

AXONOV (talk) ⚑ 07:22, 4 June 2023 (UTC)

Nowhere have I said that the range of addresses used for memory-mapped I/O isn't fixed.

What I've said is that the specific addresses for individual devices aren't necessarily fixed and, in cases where they are, they're fixed by the device, not by the system. Guy Harris (talk) 11:12, 4 June 2023 (UTC)