x86 i/o management
|
From: Noob on 10 May 2010 10:17 Quadibloc wrote: > Andy 'Krazy' Glew 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 boot-up to tell it that this range of > memory addresses is I/O, please don't cache it. Are you referring to Memory Type Range Registers? http://en.wikipedia.org/wiki/Memory_Type_Range_Registers
From: kenney on 10 May 2010 13:41 In article <4BE72A38.1040100(a)patten-glew.net>, ag-news(a)patten-glew.net (Andy 'Krazy' Glew) wrote: > 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. Just as important in the 8 bit days was that it saved memory. Also if the number of I/O ports was limited the address bus did not need to be fully decoded which saved lines on an external bus. The Z80 and I think the 8080 had a control line which distinguished between I/O port and memory access. Of course that was using I/O chips with a limited number of registers. Modern devices have far more. Ken Young
From: Jeremy Linton on 10 May 2010 15:24 On 5/9/2010 4:33 PM, Andy 'Krazy' Glew wrote: > 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. As someone who writes a fair number of drivers in C, I fail to see how memory mapped register windows provide me any benefit over IO mapped ones. The extra pain of fencing far outweighs the advantage of writting code which obscures the fact i'm writting a device register (aka pointer offset with casts). In code I write I almost always have macros of the form WRITE_REGISTER_32BITS(dev,REGISTERNAME,value) etc.. Those could just as well be doing IN/OUT. I really never understood the push for memory mapping everything (especially registers). Plus, I can't remember when I last mapped something that wasn't a register window. DMA seems to be the perfered method of transferring data to/from nearly every modern device. The mappings exist only to control the device. Even graphics cards which trandionally map a fair amount into the address space, apparently work better using double buffering methods. Plus, the most common io mechanisms often don't exactly lend themselves to direct device mapping into a user buffer. So in the end, I end up doing a lot of copy_in/out if the device cannot DMA directly into a pinned user allocated buffer. This kills performace and is probably my number one gripe about a couple of devices I've used recently.
From: Joe Pfeiffer on 10 May 2010 15:49 Jeremy Linton <reply-to-list(a)nospam.org> writes: > On 5/9/2010 4:33 PM, Andy 'Krazy' Glew wrote: >> 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. > > As someone who writes a fair number of drivers in C, I fail to > see how memory mapped register windows provide me any benefit over IO > mapped ones. The extra pain of fencing far outweighs the advantage of > writting code which obscures the fact i'm writting a device register > (aka pointer offset with casts). In code I write I almost always have > macros of the form WRITE_REGISTER_32BITS(dev,REGISTERNAME,value) > etc.. Those could just as well be doing IN/OUT. Back in the Olde Days, when you didn't have to worry about instruction reordering or cross-platform compability, you could just define a struct corresponding to the device registers and use plain ol' assignment statements. Also, at one time nearly any device I ever saw on a PDP-11 or VAX had nicely designed control registers so doing things like or'ing a bit to set it worked as expected. None of those assumptions have been true for decades now, of course. > I really never understood the push for memory mapping > everything (especially registers). Plus, I can't remember when I last > mapped something that wasn't a register window. DMA seems to be the > perfered method of transferring data to/from nearly every modern > device. The mappings exist only to control the device. > Even graphics cards which trandionally map a fair amount into > the address space, apparently work better using double buffering > methods. > Plus, the most common io mechanisms often don't exactly lend > themselves to direct device mapping into a user buffer. So in the end, > I end up doing a lot of copy_in/out if the device cannot DMA directly > into a pinned user allocated buffer. This kills performace and is > probably my number one gripe about a couple of devices I've used > recently. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: MitchAlsup on 10 May 2010 18:25
On May 10, 2:24 pm, Jeremy Linton <reply-to-l...(a)nospam.org> wrote: > On 5/9/2010 4:33 PM, Andy 'Krazy' Glew wrote: > > > 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. > > As someone who writes a fair number of drivers in C, I fail to see how > memory mapped register windows provide me any benefit over IO mapped > ones. Just try to read a 64-bit quantity into RAX with an IN instruction or the converse with an Out instruction. > The extra pain of fencing far outweighs the advantage of writting > code which obscures the fact i'm writting a device register (aka pointer > offset with casts). In code I write I almost always have macros of the > form WRITE_REGISTER_32BITS(dev,REGISTERNAME,value) etc.. Those could > just as well be doing IN/OUT. At this level of abstraction, the model does not mater. However, I expect that it is a lot harder to virtualize In and Out than the memory mapped device stuff, even if it is detected later in the pipeline and causes all sorts of miscreant activities. {However**2--SPARC's model of Address Spaces is even worse.} > I really never understood the push for memory mapping everything > (especially registers). Plus, I can't remember when I last mapped > something that wasn't a register window. DMA seems to be the perfered > method of transferring data to/from nearly every modern device. The > mappings exist only to control the device. Why would anyone want to DMA from the keyboard device? or the power button? There is a whole class of I/O that is so slow that doing anything other than programmed I/O makes little sense. {Nor does it make any sense for the great-big-Out-of-Oder Number Cruncher to perform these miniscule acts of I/O.} > Plus, the most common io mechanisms often don't exactly lend themselves > to direct device mapping into a user buffer. So in the end, I end up > doing a lot of copy_in/out if the device cannot DMA directly into a > pinned user allocated buffer. This kills performace and is probably my > number one gripe about a couple of devices I've used recently. And the prime rational for the I/O MMU things--get rid of the data copy and prevent a malformed or maltransfered address from crashing the whole machine. Mitch |