On 17/10/17 12:17, Liu Hao wrote:
> On 2017/10/17 17:13, David Brown wrote:
>> I understand about dependencies. (I also know about memory clobbers,
>> but these tend to be a fairly blunt instrument and can lead to wasted
>> cpu cycles, especially on RISC cpus with lots of registers. When you
>> are dealing with things like critical sections with interrupts disabled,
>> you are often trying to minimise the cycle time.) My solution to this
>> particular ordering problem is:
>>
>> uint32_t status;
>> asm volatile ("mrs %0, PRIMASK" : "=r" (status) :: );
>> asm volatile ("cpsid i" :: "" (status) :);
>>
>> foo();
>>
>> asm volatile ("msr PRIMASK, %0" :: "r" (status) : );
>>
>>
>> The dependency on "status" in the "cpsid i" assembly line ensures that
>> it must be ordered after the "save PRIMASK" line. However, I know of no
>> clear way - other than a potentially costly memory clobber - of forcing
>> the ordering of the "cpsid i" assembly before foo(), and the "restore
>> PRIMASK" line after foo().
>
> Yeah, just create another artificial dependency:
>
> ```
> uint32_t status;
> asm volatile ("mrs %0, PRIMASK" : "=r" (status) );
> asm volatile ("cpsid i" : "+r" (status) );
>
> foo();
>
> asm volatile ("msr PRIMASK, %0" : "+r" (status) );
> ```
>
The first "+r" here says that not only is status needed as an input
(forcing the ordering of "mrs" before "cpsid"), but that it might change
(forcing the ordering of "cpsid" before "msr"). The second "+r" does
nothing, since "status" is not used after the "msr".
But neither change affects the ordering of the asm volatile statements
with foo() - either gcc allows movements of asm volatile across unknown
code, or it does not.
> I know no ARM assembly and this idea comes from my knowledge of x86
> assembly. Please correct me if I am wrong.
>
