x86 i/o management
|
From: nmm1 on 11 May 2010 16:36 In article <1bpr12nrcp.fsf(a)snowball.wb.pfeifferfamily.net>, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: >> >> 6.7.3 #6 states "An object that has volatile-qualified type may be >> modified in ways unknown to the implementation or have other unknown >> side effects." >> >> There is nothing there about invalidating the behaviour defined for >> the abstract machine. Yes, one interpretation is that it allows >> that, but the consensus in WG14 was that it didn't, at least during >> the standardisation of C90 and C99. God alone knows whether that >> is still the case .... > >What does invalidating the behavior of the abstract machine have to do >with anything? That's a clear statement that other things can affect >the value of a volatile object at any time -- exactly as IO devices will >do. That was Jean-Marc Bourguet's correction to my original posting. But one of the ways in which device registers are used is to read or write data from an address stored in those registers, and that DOES invalidate the behavior of the abstract machine. The point is that updating device registers alone is not enough for I/O. You need to be able to pass over an address and length, and to date the memory described by those. And that is NOT allowed for in 6.7.3 #6. Regards, Nick Maclaren.
From: Andy 'Krazy' Glew on 11 May 2010 22:52 On 5/11/2010 10:28 AM, Joe Pfeiffer wrote: > 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. IIRC in C the fields must be in the order specified by the programmer. Of course, what does that mean if you are accessing a big endian device on a little endian machine? As for bitfields... However, the padding and alignment restrictions can differ.
From: Joe Pfeiffer on 12 May 2010 01:03 Andy 'Krazy' Glew <ag-news(a)patten-glew.net> writes: > On 5/11/2010 10:28 AM, Joe Pfeiffer wrote: >> 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. > > IIRC in C the fields must be in the order specified by the programmer. > Of course, what does that mean if you are accessing a big endian > device on a little endian machine? As for bitfields... I don't remember whether they have to be in the order specified. But once "order" is endian-dependant, it really doesn't matter. > However, the padding and alignment restrictions can differ. -- 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: Benny Amorsen on 12 May 2010 07:18 Bernd Paysan <bernd.paysan(a)gmx.de> writes: > Wasn't the "volatile" modifier introduced to make it easy to use that > approach with more modern compilers (and hardware)? Possibly, but it wasn't successful. The only thing you can universally rely on with volatile is that it makes global variables consistent across longjmp. Not that there is anything wrong with having a facility for that; the naming is just unfortunate and the wording in the standards at best unclear. For hardware access, you need to consult with compiler and hardware documentation. For some people, the hardware access and memory barrier functions of the Linux kernel (across architectures) can be an educational read. Note that they are gcc-specific, so you can't rely on them with other compilers. You can't write portable hardware access code in Standard C; the specification simply isn't strong enough. /Benny
From: Ken Hagan on 12 May 2010 08:04
On Tue, 11 May 2010 20:21:39 +0100, <nmm1(a)cam.ac.uk> wrote: > 6.7.3 #6 states "An object that has volatile-qualified type may be > modified in ways unknown to the implementation or have other unknown > side effects." Could "may [...] have other unknown side effects" be worded any less helpfully for someone trying to write portable code? |