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

Bernd Walter enut at cicely.de
Tue Apr 26 22:37:44 CEST 2011


On Tue, Apr 26, 2011 at 07:25:54PM +0200, Harald Kipp wrote:
> On 4/26/2011 6:45 PM, Bernd Walter wrote:
> > On Tue, Apr 26, 2011 at 02:55:28PM +0200, Harald Kipp wrote:
> >> 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.

Right, but on the other hand adding barriers disallows the compiler to
do other optimizations, which I believe are more likely.
Using barriers instead of volatiles is not costless.
With barriers the compiler is still free to cache local variable in
regisers, since the compiler has a complete view about their use.
But whenever you use other variables the barrier will force additional
memory and instruction cycles.
Of course it is debatable which one has more potential.
In my opinion it is easier for the programmer to get most of the
register reorder win, by writing reasonable code without loosing the
other optimizations, which are impossible to get back.
And you are calling for new kind of programming bugs.
E.g. writing two times the same value to the same register as required
for SPI reset workaround on some AT91.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.


More information about the En-Nut-Discussion mailing list