[En-Nut-Discussion] Hardware Register Access Using Volatile Pointer

[Harald Kipp]

On 4/26/2011 6:45 PM, Bernd Walter wrote:
> On Tue, Apr 26, 2011 at 02:55:28PM +0200, Harald Kipp wrote:

>> Definitely there are no pros for using the "Atmel style", except
>> personal preference:
>
> It personally think typesafe controller pointers are pro.

That's a problem with macros. inr() can and should be defined as an 
inline function. Again, see the flexibility.


>> This is even tricky within Nut/OS. Following the good old style of
>> avr-libc, we try to use port and bit names from the datasheet. This
>> helps to remember the names. The bad thing is that Atmel datasheets are
>> not written with C programming in mind.
>
> Yes - that's definitive a pro for the other way.

No. The other style only works, because it ignores assembly language. 
Actually Atmel offers both, for example

#ifndef __ASSEMBLY__
typedef struct _AT91S_EC
         AT91_REG ...
} AT91S_ECC, *AT91PS_ECC
#else
#define ECC_...
#endif

Isn't this a nightmare?


> Buty I don't fight for either style.

In any case, I appreciate your comments.


>> My view differs. If the programmer knows better, than he better use
>> memory barriers instead of volatiles. Simple reason: There are cases,
>> where the order of I/O register reading and writing is not important at
>> all. Why not let the compiler decide and only use memory barriers where
>> required?
>
> True, but do you think that the programmers order is usually that bad?
> If you read/write 10 registers without specific order requirement.
> How likely do you think that the compiler can gain a win by reordering
> them?

I agree, that in most cases there will not be much room for 
optimization. But if there is room, the programmer will not be able to 
see it. The decisions are made on register level, which is beyond the 
imagination of the programmer.


> Fortunately someone already came up with a definitive documentation.

Yes, many thanks to Bernard again.

> This is GCC documentation and not C, so you still might have doubts about
> other compilers...

Sure, this needs to be solved for each compiler individually.

Regards,

Harald