Re: Portable memory barrier?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 17-05-06 22:41 , Jeffrey R. Carter wrote:
> On 05/06/2017 04:17 PM, Jere wrote:
>>
>> Side note:  If I read it right, you seemed to indicate that volatile
>> has nothing
>> to do with sequence.  I'm no Ada expert, so I wanted to ask your
>> interpretation
>> of section 16/3 of C.6.  I'm used to C and C++ where if you have two
>> volatile
>> variables being updated like this:
>>
>> Vol_Var_1 = 0;
>> Vol_Var_2 = 23;
>>
>> That the C and C++ standard guarantees the "compiler" will not reorder
>> those two
>> statements.  Note this says nothing about atomicness (which is only
>> one reason
>> among others why Volatile is not sufficient for threading).  It also
>> doesn't
>> prevent the processor from reordering them.  When I read that section
>> in C.6 of
>> the RM, the verbage made me think Ada also prevented the compiler from
>> reordering the statements (again no relation to atomicness or CPU
>> reordering).
>>
>> Is this not the case?
>
> Volatile is intended to guarantee that all reads and writes deal with
> the memory location directly.

Well... for some value of "directly". As I understand it, reading or 
writing a volatile variable can still use the cache, so depending on the 
cache architecture and state, a read may or may not read the "real" 
memory, and ditto for a write.

> The idea is for things like memory-mapped
> H/W registers, where the H/W might change the value of the register or
> writing to the register causes the H/W to do something.

And such registers are usually defined in the HW as non-cacheable, so in 
the end volatile access to such registers works as intended, and as you say.

> This prevents
> optimizations that keep the value in a register for a while before
> writing it back to memory, for example, but not reordering the accesses
> to different variables IIUC.

Just as in C, volatile accesses in Ada are guaranteed to occur in the 
order and number written in the source code and executed in the 
"standard" order:

RM C.6 (16/3): All tasks of the program (on all processors) that read or 
update volatile variables see the same order of updates to the 
variables. A use of an atomic variable or other mechanism may be 
necessary to avoid erroneous execution and to ensure that access to 
nonatomic volatile variables is sequential (see 9.10).

RM C.6 (20): The external effect of a program (see 1.1.3) is defined to 
include each read and update of a volatile or atomic object. The 
implementation shall not generate any memory reads or updates of atomic 
or volatile objects other than those specified by the program.


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .