x86 i/o management
|
From: yoxoman on 9 May 2010 14:17 Hello, It seems that x86 architecture manages i/o communication through i/o ports as well as memory-mapped i/o (refering to the content of /proc/ iomem and /proc/ioports on my OS). Is the Intel management of both types of i/o communication just due to historical constraints (and i/o ports management is just reffering "old" devices) ? Or are there advantages of i/o ports management on memory- mapped i/o ? Sorry if the question is obvious, I'm just trying to learn much of the wide world of computer architecture, and asking myself many questions on which I don't always get precise answers in books / on the net. If such questions should not take place in that group, please tell me. Thanks.
From: Bernd Paysan on 9 May 2010 17:22 yoxoman wrote: > Is the Intel management of both types of i/o communication just due to > historical constraints (and i/o ports management is just reffering > "old" devices) ? Or are there advantages of i/o ports management on > memory- mapped i/o ? Apart from being compatible with computers a quarter of a century ago, this is just legacy. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
From: Andy 'Krazy' Glew on 9 May 2010 17:33 On 5/9/2010 2:22 PM, Bernd Paysan wrote: > yoxoman wrote: >> Is the Intel management of both types of i/o communication just due to >> historical constraints (and i/o ports management is just reffering >> "old" devices) ? Or are there advantages of i/o ports management on >> memory- mapped i/o ? > > Apart from being compatible with computers a quarter of a century ago, > this is just legacy. There are advantages to I/O ports over memory mapped I/O. Basically, it tells the processor earlier, before address decode, that it is likely to involve a serialization. However, by now I/O ports are mainly just legacy. Memory mapped I/O rules, largely because of the ease of writing C device drivers to access the control registers of such devices. So all memory accesses are burdened with the cost of determining that a location is or is not a memory mapped I/O location, with possible side effects.
From: Quadibloc on 10 May 2010 08:13 On May 9, 3:33 pm, Andy 'Krazy' Glew <ag-n...(a)patten-glew.net> wrote: > So all memory accesses are burdened with the cost of > determining that a location is or is not a memory mapped I/O location, with possible side effects. I thought there was some kind of table inside the microprocessor that gets set by the BIOS during bootup to tell it that this range of memory addresses is I/O, please don't cache it. And in modern ones, there would even be another table that says this range of addresses are 16 bits wide, so just use 16 out of the 64 bits of your data bus, and start using the lower bits of your address bus. Not having been tasked with designing a set of support chips for a microprocessor, though, I hadn't gotten around to actually reading those parts of the manuals yet, so it could be stranger than I have imagined. John Savard
From: nmm1 on 10 May 2010 09:34
In article <558f30f4-1499-43da-b4f7-0fd85544c0da(a)37g2000yqm.googlegroups.com>, Quadibloc <jsavard(a)ecn.ab.ca> wrote: >On May 9, 3:33=A0pm, Andy 'Krazy' Glew <ag-n...(a)patten-glew.net> wrote: >> So all memory accesses are burdened with the cost of >> determining that a location is or is not a memory mapped I/O location, >>with possible side effects. > >I thought there was some kind of table inside the microprocessor that >gets set by the BIOS during bootup to tell it that this range of >memory addresses is I/O, please don't cache it. And in modern ones, >there would even be another table that says this range of addresses >are 16 bits wide, so just use 16 out of the 64 bits of your data bus, >and start using the lower bits of your address bus. That's only the beginning of the gotchas :-( Think about interaction with the out-of-order logic, especially if roll-back is needed. Even at an abstract, mathematical, level, that makes my head hurt! As you might expect, signal handling rears its ugly heads here, and a LOT of systems have failed horribly if the wrong kind of signal gets too close to an I/O activity. >Not having been tasked with designing a set of support chips for a >microprocessor, though, I hadn't gotten around to actually reading >those parts of the manuals yet, so it could be stranger than I have >imagined. I should be flabberghasted if it wasn't! The last time that I did any I/O at that level was on a System/370, which is Seriously Different, but I have glanced at some of the architectures and most of what I would need to know to write a reliable device driver was stated to be only in the (often unpublished) chip specification. Which can be, of course, different for every version. Regards, Nick Maclaren. |