x86 i/o management
|
From: MitchAlsup on 10 May 2010 23:24 On May 10, 9:33 pm, Andy 'Krazy' Glew <ag-n...(a)patten-glew.net> wrote: > On 5/10/2010 3:25 PM, MitchAlsup wrote: > {However**2--SPARC's model of Address Spaces is even worse.} > > Ooops. I just said I liked SPARC alternate address spaces. But, I have never implemented them, whereas you have, > Mitch. Tell us why they are worse, eh? Its the practice, not so much the 'original' intent (V7, V8). x86 uses msrs and CPUID to access various tidbits of information contained in the CPU, while SPARC uses one ASIs to access <this thing> or <that thing>. Each ASI is supposed to access a different kind of space. There is the space to access an alternate address space, a space to access the TLB (load, flush), a space to access 2nd or 3rd level cache functions (flush, setups), a space to access diagnostice, a space to access debugg registers, spaces to access cache tags {l1,L2,L3,...}, spaces to do 16-bit I/O, spaces to do 32-bit I/O, spaces to do 64-bit I/O that are not the same spaces.... a space to do this and a space to do that. With 12-bits of space ID is easy to just assume you have plenty of spaces. Even the default load and store (to nromal cacheable memory) have default ASIs. So, in the pipeline (decode), you assume the ASI does normal stuff (like access alternate translations) and then figure out it doesn't and (sort of) microfault back to a safe point and then peform the access with the strict kind of access order required for CPUID-stuff or msr-stuff (internal CPU register). You conceivably have room in the decoder to translate the ASI into msr or CPUID like accesses--kinda contrary to the notion of RISC--but that is a different story. In any event, due to the nature of the access path (via the memory pipe) you tend to locate these control register in the memory area of the chip and just use the load/store pipes to access these, and add the horse- play to make sure memory order wrt control register orders are not violated. It is this that is messy. Overall, it is this msr versus memory variant of IN/OUT versus MMIO; that is not nearly as clean as the msr or CPUID additions to x86. Mitch
From: Bernd Paysan on 11 May 2010 10:58 Joe Pfeiffer wrote: > 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. Wasn't the "volatile" modifier introduced to make it easy to use that approach with more modern compilers (and hardware)? About ways to deal with that sort of different "memories": x86 has most of them: IO mapped IO, different attributed memory regions (i.e. IO mapped memory is attributed as "non-cachable" etc.), and instructions which bypass caches on purpose (SSE). The only thing missing is the channel controller or similar - the solution of the problem by offloading it to a special- purpose hardware. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: John Levine on 11 May 2010 12:08 >caches on purpose (SSE). The only thing missing is the channel controller >or similar - the solution of the problem by offloading it to a special- >purpose hardware. Where's the 8089 now that we need it? R's, John
From: Joe Pfeiffer on 11 May 2010 13:28 Bernd Paysan <bernd.paysan(a)gmx.de> writes: > Joe Pfeiffer wrote: >> 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. > > Wasn't the "volatile" modifier introduced to make it easy to use that > approach with more modern compilers (and hardware)? Yes, except order of the fields in the struct is up to the compiler. We can have pointers to the offsets put in by hand. > About ways to deal with that sort of different "memories": x86 has most of > them: IO mapped IO, different attributed memory regions (i.e. IO mapped > memory is attributed as "non-cachable" etc.), and instructions which bypass > caches on purpose (SSE). The only thing missing is the channel controller > or similar - the solution of the problem by offloading it to a special- > purpose hardware. -- 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: nmm1 on 11 May 2010 13:40
In article <1bwrva4aax.fsf(a)snowball.wb.pfeifferfamily.net>, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: >Bernd Paysan <bernd.paysan(a)gmx.de> writes: > >>> 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. >> >> Wasn't the "volatile" modifier introduced to make it easy to use that >> approach with more modern compilers (and hardware)? > >Yes, except order of the fields in the struct is up to the compiler. We >can have pointers to the offsets put in by hand. Also, no. 'volatile' in C was a Committee Compromise (an insulting term) that put in some vague wording intended to provide facilities that were being demanded by two camps, and that was one. As a result, it is unsatisfactory for both uses and, in particular, doesn't help with device register support. In particular, accessing a volatile object is not allowed to have any effect on any OTHER object visible to the program, which rather defeats the object of using it for I/O. Regards, Nick Maclaren. |