x86 i/o management
|
From: Joe Pfeiffer on 11 May 2010 14:15 nmm1(a)cam.ac.uk writes: > 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. I have never seen this claim regarding the keyword before. Where in the standard does it appear? -- 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: Jean-Marc Bourguet on 11 May 2010 14:25 nmm1(a)cam.ac.uk writes: > '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. Which was the other? > 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 I think you forgot non-volatile here ^ > program, which rather defeats the object of using it for I/O. Yours, -- Jean-Marc
From: nmm1 on 11 May 2010 15:14 In article <8739xy47pb.fsf(a)news.bourguet.org>, Jean-Marc Bourguet <jm(a)bourguet.org> wrote: > >> '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. > >Which was the other? Asynchronous flags etc. - e.g. ones set by asynchronous signal handlers, other threads and so on. >> 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 > >I think you forgot non-volatile here ^ Thank you for the correction. I did. Regards, Nick Maclaren.
From: nmm1 on 11 May 2010 15:21 In article <1bsk5y485m.fsf(a)snowball.wb.pfeifferfamily.net>, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: >> >> '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. > >I have never seen this claim regarding the keyword before. Where in the >standard does it appear? Implicit in its basic design :-( 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 .... Regards, Nick Maclaren.
From: Joe Pfeiffer on 11 May 2010 15:57
nmm1(a)cam.ac.uk writes: > In article <1bsk5y485m.fsf(a)snowball.wb.pfeifferfamily.net>, > Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: >>> >>> '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. >> >>I have never seen this claim regarding the keyword before. Where in the >>standard does it appear? > > Implicit in its basic design :-( > > 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. -- 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) |