LINUX.ORG.RU

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

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 ★★ ()

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

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

aton ()

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

aton:

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

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

Die-Hard ★★★★★ ()
Ответ на: Re: Оптимизация и волатильные переменные от devinull

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

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

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

devinull ★★ ()

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

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

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

те,
        volatile int *pv;

        *pv;

        ....;

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

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

idle ★★★★★ ()

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

2idle:

Thanks,

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

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

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

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

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

Die-Hard ★★★★★ ()
Ответ на: Re: Оптимизация и волатильные переменные от Die-Hard

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

> 1. ...

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

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

> 2. ...

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

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

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

idle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.