memory barrier problem in driver development

On Wed, 10 Dec 2008 18:20:41 -0800 (PST), leilei wrote in comp.arch.embedded:

We should consider providing enough information for somebody to begin to answer your question. Such as:

What kind of processor architecture (Core 2 Quad or 8051)?

What kind of device?

Memory mapped or I/O mapped device?

Operating system?

Without this kind of information, the only answer anyone can give to your question is "maybe"?

tml

I am sorry. I am a fresh in driver development, I did not realise there are so many problem need to be considered. I usually write device driver based on x86 architecture, use gcc to compile the source.Ths OS is developed by our own company.

I know the memory barrier when I read Linux kernel source code.But I do not know how and when to use it properly.

A safer answer is "yes" (after all, he asked if they should *consider* using memory barriers).

Memory barriers are normally implemented as a macro. If you are writing code that you want to be portable, use memory barriers in the low-level driver code. When compiling for different architectures, the macro definition will be different - on the 8051 it might be empty, while on the PPC it might be something like:

asm volatile(" eieio " : : "memory")

Hi, I have been looking for materials for these things. some article mentioned volatile key words.

I want to know what's the difference between volatile and macro like asm volatile(" eieio " : : "memory"). how to use these two things correctly.

Briefly, volatile instructs the *compiler* to prevent re-ordering, while "eieio" instructs the PowerPC CPU to prevent re-ordering. Obviously, the "eieio" is a PowerPC specific instruction. Other (not all) processors have similar instructions as required.