Memory Barrier

[Thomas Doerfler]

Till,

Till Straumann schrieb:
>>>       _CPU_MSR_GET(msr);
>>>       new_msr = msr | MSR_EE;
>>>       _CPU_MSR_SET(new_msr);
>>>        ...........
>>>       ............
>>>       _CPU_MSR_SET(msr);
>>>     
>>
>> Hm, I think this is also not a problem.
>>
>> The compiler is not allowed to move the assignments to "msr" and
>> "new_msr", because they are used in the next statements.
>>   
> The problem is that the compiler may move code from after
> _CPU_MSR_SET(msr) upstream to before it is set thus
> moving code into a section that is not protected from interrupts.
> Or it may ignore the fact that global variables could change
> between the first MSR_Set (enabling interrupts) and the
> second one (disabling interrupts).

Ok, Till, agreed. The sample lines Kate mentioned in her previous
posting made me think about problems concerning the "new_msr" and "msr"
variables. You are right that this operation needs a memory barrier to
avoid dangerous compiler optimizations.

wkr,
Thomas.



-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request