|This is the talk page for discussing improvements to the Memory-mapped I/O article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing / Software / Hardware||(Rated C-class, Mid-importance)|
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)
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)
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.
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. --22.214.171.124 (talk) 03:45, 25 October 2008 (UTC)
"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)