x86 i/o management
|
From: nmm1 on 12 May 2010 08:20 In article <m38w7pgygi.fsf(a)ursa.amorsen.dk>, Benny Amorsen <benny+usenet(a)amorsen.dk> wrote: > >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. Actually, only a real language lawyer and extremely cynical and experienced programmer can rely on even that! It doesn't mean that you can call longjmp from a signal handler or other asynchronous code, but the real gotcha is 6.7.3 #3: "The properties associated with qualified types are meaningful only for expressions that are lvalues." The consequences of that are unbelievably unobvious - even to people who are C standard experts. I got caught by one, once, and ended up deciding that the standard was semantically ambiguous even for this simple case. >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. Agreed. Regards, Nick Maclaren.
From: Anton Ertl on 12 May 2010 08:22 Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> writes: >I don't remember whether they have to be in the order specified. They have to. > But >once "order" is endian-dependant, it really doesn't matter. The order of fields is not byte order dependent. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: Bernd Paysan on 12 May 2010 09:55 Benny Amorsen wrote: > 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. Well, this reflects more the decision of the GCC team to not implement all kinds of strange memory barrier functions inside the compiler, but expose a way to implement it on the other side. This is a pragmatic approach, shifting the burden to the people who probably know better how to deal with these things, anyways. But it's inherently non-portable. The way I would implement volatile is by saying "volatile obviously was meant to deal with memory mapped IO, so let's implement an access to a volatile address as such", no matter what the actual spec tries to weasel- word to achieve consensus in a committee. Volatile may *not* be sufficient if your hardware has non-cache coherent DMA capability, because that requires cache invalidation and such. But for the usual cases like memory mapped IO, shared variables for multi-threaded applications, and variables updated in signal handlers and accross setjmp/longjmp, volatile should work. If not, this is poor implementation quality of the compiler. > You can't write portable hardware access code in Standard C; the > specification simply isn't strong enough. With all the language lawyering I came to the conclusion that you can't write anything useful in Standard C anyways - the specification is simply too weak. And if the language lawyers at GCC ask questions like "why is LLVM getting more attention than our huge lump of unmaintainable 20 year old code base", maybe the weak spec they are tracking is part of the problem - LLVM is trying to achieve something more useful (provide a low level virtual machine - i.e. one where the spec is not a language standard). -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/
From: nmm1 on 12 May 2010 10:30 In article <hsec0c$g71$1(a)news.m-online.net>, Bernd Paysan <bernd.paysan(a)gmx.de> wrote: > >But for the >usual cases like memory mapped IO, shared variables for multi-threaded >applications, and variables updated in signal handlers and accross >setjmp/longjmp, volatile should work. If not, this is poor implementation >quality of the compiler. That is NOT true! Inter alia, there is no memory ordering implied between threads or 'real' signal handlers, so every non-volatile variable becomes undefined - whether or not it was updated in the critical section. And that can happen when you enable non-trivial optimisation :-( C's volatile is a disaster area. Regards, Nick Maclaren.
From: Nicholas King on 12 May 2010 11:08
On 05/13/2010 12:30 AM, nmm1(a)cam.ac.uk wrote: > C's volatile is a disaster area. Can't we shorten this to "C's a disaster area."? Cheers, Nick King |