Оптимизация и волатильные переменные

The least requirements on a conforming implementation are:

— At sequence points, volatile objects are stable in the sense that previous evaluations are complete and subsequent evaluations have not yet occurred.

Это из стандарта. Оно?

нет не можешь, но эти перестановки в любом случае не должны
отражаться на конечном результате

devinull :

Thanks, вроде, оно...

А откуда это?

И как там определяются sequence points?

aton:

> нет не можешь, но эти перестановки в любом случае не должны отражаться на конечном результате

Дык, вторая часть этого предложения не стыкуется с первой: компилятор просто не может предположить, зачем я читаю из волатильных переменных...

мой жабер есть в профиле ;)

Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.7

Найди меня в жабере, скину книгу.

2devinull:

Thanks,

У меня жабера нет.

Напишу мылом -- он у тебя правильный?

286780015 - моя ася. И мыло правильное.

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

на стандарт сослаться не могу (тк не читал), но сильно
уверен, что можешь. более того, любое обращение к "volatile"
_должно_ быть compiler barrier, иначе компилятор broken.

те,
        volatile int *pv;

        *pv;

        ....;

компилятор обязан выполнить *pv до ...

НО! процессор может переупорядочить. поэтому, для гарантии -
rmb(). 

2idle:

Thanks,

> НО! процессор может переупорядочить. поэтому, для гарантии - rmb().

Несколько вопросов по этому поводу.

1. А если я между ними делаю атомарную операцию с блокировкой шины (над совсем другой переменной), это не будет означать для процессора наличия барьера?

2. А насколько rmb() переносим? Всегда ли я его найду в include/asm/system.h ?

3. Насколько я понимаю, i386 ничего не переупорядочит, правильно? Это отосится ко всем разновидностям IA32? А как насчет Итаниума и Оптерона?

Ты мне отписался в почту?

2devinull:

Только что с хотмэйла написАл.

Извиняюсь, весь день бегал.

Спасибо заранее.

А я сам только вернулся. ;) Отправил письмо. Надеюсь, не напряжет, что там аж 2 метра?

> 1. ...

не знаю. но думаю - нет. но не знаю :) уж больно это
завязано на низкоуровневую магию.

atomic_add(), к примеру, барьера _не_ гарантирует. но,
возможно это только для простора в реализации, а ты
говоришь только о rmb().

> 2. ...

опять-таки, не знаю. а в libpthread ничего такого нет?
этот asm/system.h все-таки из ядра.

> 3. Насколько я понимаю, i386 ничего не переупорядочит, правильно?

нет, может. stores - те да, ordered. чтение - нет. по
той хотя бы простой причине что i386 может это... как
его... ну когда несколько инструкций "одновременно"
если нет зависимостей.