Всем привет!



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



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


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

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

Ребят, кто-нибудь поделится знаниями?

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

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

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

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

С форума.



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

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


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

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

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

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





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

Про исключения из правила не менять порядок доступа к volatile-переменным? Не увидел. Где?

Я согласен с первой цитатой. Хотя пример из avr-gcc не согласуется с ней

Если посреди развесистой функции с кучей локальных переменных, которые к моменту появления барьера уже все в регистрах, то оверхед может быть приличным.

Тут все просто Надо немножко погуглить на предмет "memory barrier", "out of order execution", "cache coherency" На хабре был цикл очень хороших статей по этому поводу..
Где-то в этом районе:
http://habrahabr.ru/company/ifree/blog/196548/



Самое забавное, не в том, что компилятор может нагенерить, а то, процессор может выполнять инструкции не в том порядке, в котором они лежат в памяти..

если отвлечься от армовской (?) архитектуры, то это _compiler_barrier, а бывают еще _machine_barrier (в спарке v8 он например вставляет flush), то есть можно почитать для SPARC-а про формализацию моделей памяти TSO, PSO и т.д.
у современных х86 тоже должно быть интересно, но я не в теме

Это я знаю, но в данный момент меня интересуют более простые ситуации

В данный момент обсуждаем именно барьер компилятора.

Спасибо за ссылки.
Вот в этой статье вижу противоречие с этой статьей (в ней есть ссылка на официальную документацию GCC):





Видимо, в этой ситуации лучше доверять официальной документации GCC, т. е., asm volatile вставки компилятор не может выбрасывать, но может "перетаскивать" и немного оптимизировать согласно стратегии своей работы.

Там дальше (в официальной документации) есть разъяснение, как этого избежать. (Добавить искусственную зависимость от переменной, относительно операции с которой мы не хотим, чтобы компилятор двигал asm volatile вставку.
А поскольку зависимость "memory" - самая сильная (она означает зависимость от всех переменных), то, вероятно, барьер типа asm volatile (::: "memory") компилятор передвинуть никак не может.