Барьер компилятора 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;
}

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

[koluna]

Откуда у вас такие цитаты?

С форума.

Насколько я знаю, обращение к volatile переменным компилятор менять не имеет права.

Я тоже так думал, но, судя по всему бывают исключения...

http://blog.regehr.org/archives/28

and also accesses to volatiles should not be reordered (with some exceptions).

http://www.nongnu.org/avr-libc/user-manual/optimization.html

memory barriers don't ensure statements with no volatile accesses to be reordered across the barrier

[AHTOXA]

Я тоже так думал, но, судя по всему бывают исключения...

Нет, менять местами обращение к volatile-переменным компилятор не имеет. Собственно, про это и написано в ссылке.
То, что сделал avr-gcc в примере с cli()/sei() - может быть просто багом avr-gcc.

[koluna]

Нет, менять местами обращение к volatile-переменным компилятор не имеет. Собственно, про это и написано в ссылке.
То, что сделал avr-gcc в примере с cli()/sei() - может быть просто багом avr-gcc.

Там еще про некоторые исключения написано

А между цитатами из первой и второй статьи вижу противоречие:

Moreover, code motion is not permitted around the barrier in either direction

memory barriers don't ensure statements with no volatile accesses to be reordered across the barrier

Интересно, какой оверхед дает использование барьера?

Сообщение отредактировал koluna - Aug 30 2014, 13:02