Барьер компилятора asm volatile ("" ::: «memory») Опции

[koluna]

Всем привет!

Конструкция не содержит никаких инструкций и является барьером, говорящим компилятору: “сбрось все регистры в RAM до барьера и перечитай после”.

Расскажите, пожалуйста, поконкретнее, что же делает на самом деле этот барьер помимо действий, описываемых фразой, приведенной выше.

Барьеры обеспечивают надлежащий порядок доступа к volatile переменным и не обеспечивают надлежащий порядок доступа к не volatile переменным (может происходить перебрасывание через барьер).

Почему? Что это значит?

Код

volatile x, y, z;
x = 1;
y = 2;
z = 3;

Может ли компилятор поменять порядок обращения к volatile переменным x, y, z?
Т. е., влияет ли как-нибудь volatile на порядок обращения к переменным или нет?
Насколько далеко может зайти компилятор, переставляя инструкции?

Есть ли какая-либо взаимосвязь между барьером компилятора и точками следования?

[AHTOXA]

Откуда у вас такие цитаты?
Насколько я знаю, обращение к volatile переменным компилятор менять не имеет права.
А барьер этот используется для обеспечения порядка доступа к не-volatile переменным.
Приведу пример.

Код

void test(){
    enable_interrupts = 0;
    some_stuff();
    enable_interrupts = 1;
}

enable_interrupts = volatile-регистр, отвечающий за разрешение прерываний.
Без барьра компилятор делал так:

Код

void test(){
    enable_interrupts = 0;
    enable_interrupts = 1;
    some_stuff();
}

То есть, some_stuff() выполнялась при включенных прерываниях, что противоречит задумке.
Введение барьера:

Код

void test(){
    enable_interrupts = 0;
    some_stuff();
    __asm__ __volatile__ ( :::"memory");
    enable_interrupts = 1;
}

Решило проблему.
Наверное такой барьер можно считать принудительной точкой следования, но я не берусь давать чётких определений на этот счёт.