[Arlleex 131]

Я ссылки зря приводил? Там все ответы на все вопросы.

Тогда, пожалуй, отписываюсь

[AlexandrY 3]

2 hours ago, inventor said:

когда использование volatile нежелательно и может испортить работу программы?

Когда несколько volatile применяют в одной точке следования - http://alenacpp.blogspot.com/2005/11/sequence-points.html
Хотя в последнее время IAR на это ругается, но пару лет назад вполне пропускал такое.
Потом volatile по отношению к структурам и объектам или просто сложным типам в ARM-ах легко приводит к гонкам. Безопасен только доступ к переменным не длиннее 4-х байт и выровненным. 
Потом непонятно как с volatile будет в позиционно независимом коде.
Volatile создает ложное впечатление о прямом доступе к памяти, хотя если работает DMA то это не так. Надо кроме кэша  процессора обходить и кэш собственно контроллера памяти, чего volatile не делает. 
Короче volatile - это штука для профессионалов.
Если на прикладном уровне выше HAL встречается volatile то это не к добру. 

[one_eight_seven 3]

2 hours ago, AlexandrY said:

Надо кроме кэша  процессора обходить и кэш собственно контроллера памяти, чего volatile не делает. 

Строго говоря, когерентность кэша - это вопрос к аппаратной части, а не к программной. Размещением переменных в кэшируемых/некэшируемых областях памяти, равно как и инвалидацией кэша занимается не компилятор. volatile не создаёт никаких ложных ощущений, это погромист их себе создаёт. Volatile означает лишь то, что при каждом обращении к переменной будет обращение к иерархии памяти, а не работа с предыдущим значением этой переменной, которое может быть в регистрах CPU.

 

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

[AlexandrY 3]

46 minutes ago, one_eight_seven said:

Строго говоря, когерентность кэша - это вопрос к аппаратной части, а не к программной. Размещением переменных в кэшируемых/некэшируемых областях памяти, равно как и инвалидацией кэша занимается не компилятор. volatile не создаёт никаких ложных ощущений, это погромист их себе создаёт. Volatile означает лишь то, что при каждом обращении к переменной будет обращение к иерархии памяти, а не работа с предыдущим значением этой переменной, которое может быть в регистрах CPU.

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

А что такое "память процессора"  или тем более "иерархии памяти"?  Особенно когда в Cortex-M33 грозятся сделать кучу нативных сопроцессоров с огромным числом регистров и расширенной системой команд.  Тут IAR легко может сопроцессор использовать под регистры процессора. А это считай та же память доступная DMA.  
И тогда volatile ничего конкретно не означает, надо делать исследования.  

Или так уверенно заявили про "ассоциативный буфер". А  поинтересоваться какую такую память я имел в виду. А может это доступная через два шинных моста HyperRAM? У каждого моста свой буфер.  

[inventor 0]

забавная статья про volatile

 

http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf

[one_eight_seven 3]

43 minutes ago, AlexandrY said:

А что такое "память процессора"

Почему вы спрашиваете это у меня, если вы ввели этот термин?

43 minutes ago, AlexandrY said:

или тем более "иерархии памяти"

go get some education.

 

43 minutes ago, AlexandrY said:

Особенно когда в Cortex-M33 грозятся сделать кучу нативных сопроцессоров с огромным числом регистров и расширенной системой команд.  Тут IAR легко может сопроцессор использовать под регистры процессора. А это считай та же память доступная DMA.  

В огороде бузина, в Киеве - дядька.

 

43 minutes ago, AlexandrY said:

А  поинтересоваться какую такую память я имел в виду.

А зачем? Процессор всё-равно видит её через интерконнект. И тогда это либо адрес в пространстве 'device', и тогда там нет никаких контроллеров памяти, или это что-то, что помещается в RAM, и тогда там есть контроллер памяти. В устройствах могут быть свои кэши - это да, только сути не меняет.

Изменено 6 декабря, 2018 пользователем one_eight_seven

[Kabdim 0]

2 часа назад, inventor сказал:

забавная статья про volatile

 

http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf

Нашли один баг в странном сочетании совсем юного llvm и gcc как фронтенда (сочетание которое и тогда использовали полтора инвалида, а нынче давно выпилили) и для солидности добавили некорректный пример и пример "я хочу что бы компилятор работал так как я хочу, а не по стандарту". Надули щеки и сделали из этого глубокомысленные выводы. Всё ради публикации за грант. Статья и впрямь забавная, но как аргумент слабая.

ЗЫ Они там пишут что всё репортили, но как я не искал их в багтрекере гцц - не нашел.

[Stanislav 0]

On 12/3/2018 at 12:20 PM, twix said:

На мой взгляд оптимизация компиляторов вред безусловный. Никогда не знаешь как он наоптимизирует, а потом ищи где флаг не переключается или не отслеживается. Для большого проекта это тем более актуально.

Хочешь оптимизации есть масса способов сделать это надежно руками...

Да, там часто заворачивается всё довольно необычно. Но любой человек способен при желании в этом разобраться, и понять идеи, заложенные в основу работы компилятора/оптимизатора (тем более, что на сей счёт обычно есть документация). И, уж тем более, изучить правила написания программы на ЯВУ, гарантирующие правильность её исполнения.

[AlexandrY 3]

9 hours ago, Stanislav said:

Да, там часто заворачивается всё довольно необычно. Но любой человек способен при желании в этом разобраться, и понять идеи, заложенные в основу работы компилятора/оптимизатора (тем более, что на сей счёт обычно есть документация). И, уж тем более, изучить правила написания программы на ЯВУ, гарантирующие правильность её исполнения.

Тут не идеи нужны, а детерминизм входа и выхода у компилятора. Вот его в C/C++ и нету.
В Python или Java нет никакой специальной оптимизации и ничего живут.
Почему C/C++ не делают компиляцию с максимальной оптимизацией изначально? Вот в чем вопрос.

Думаю ответ в слабости отладочных движков. 

[Kabdim 0]

22 часа назад, AlexandrY сказал:

Тут не идеи нужны, а детерминизм входа и выхода у компилятора. Вот его в C/C++ и нету.

Он как раз по результату выполнения есть, если писать на C/C++, а не на той пурге которую себе воображают на месте этого языка противники оптимизации.

[AlexandrY 3]

1 hour ago, Kabdim said:

Он как раз по результату выполнения есть, если писать на C/C++, а не на той пурге которую себе воображают на месте этого языка противники оптимизации.

Эт вам так кажется.
А посмотрите на пояснение к опции оптимизации "Type-based alias analysis"

Любой код больше 100 тыс. строк будет пургой. Хотя бы потому что его будут писать много людей и в разное время.  
Нет смысла  пенять на криворуких кодеров.
Опыт говорит - даже минимальный статический анализ выдает  гору предупреждений на любой достаточно объемный код.
Потому что в C/C++ если не нарушишь правила безопасности, то не напишешь эффективный код. 

[amaora 20]

On 12/9/2018 at 2:12 PM, AlexandrY said:

Тут не идеи нужны, а детерминизм входа и выхода у компилятора. Вот его в C/C++ и нету.
В Python или Java нет никакой специальной оптимизации и ничего живут.
Почему C/C++ не делают компиляцию с максимальной оптимизацией изначально? Вот в чем вопрос.

Думаю ответ в слабости отладочных движков. 

Что мешает всегда использовать оптимизацию?

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

У gcc есть -Oz для оптимизации которая не машают отладке, но на деле я могу отлаживать с любой оптимизацией. Может быть иногда приходится смотреть дизасм, если переменная ускользнула в регистры.

 

 

[Kabdim 0]

2 часа назад, AlexandrY сказал:

Потому что в C/C++ если не нарушишь правила безопасности, то не напишешь эффективный код. 

Аргументируйте пожалуйста, нарушать правила нужно только в тонком слое прямо связанным с железом. Приведите пожалуйста пример, вне этой области где требуется нарушать правила.

[Kabdim 0]

И да, тут проскакивал аргумент для чего вообще сделана возможность компилировать без оптимизаций. Наверняка это ввели только ради кривых рук. Расскажу тем кто не знает, большие С++ проекты компилируются очень долго. Долго значит часами, а когда компютеры были маленькими могло и днями. В то же время при разработке удобно быстро скомпилировать только что написанное и посмотреть работает оно адекватно или нет. Так было принято еще до изобретения ТДД и кучи бибилиотек для него. Нижние уровни оптимизации нужны именно для ускорения цикла внесение изменений-компиляция-проверка.

[AlexandrY 3]

19 hours ago, Kabdim said:

Аргументируйте пожалуйста, нарушать правила нужно только в тонком слое прямо связанным с железом. Приведите пожалуйста пример, вне этой области где требуется нарушать правила.

На марсоходе с VxWorks часто происходили зависоны. Оказалось не ставили мьютексы предполагая что запись в простую переменную атомарная.
Я тож люблю полагаться на знание об атомарности или  изолированности доступа к переменным. Поскольку синхронизация дорогой процесс. 

47 minutes ago, Kabdim said:

Нижние уровни оптимизации нужны именно для ускорения цикла внесение изменений-компиляция-проверка.

Первый раз слышу. В IAR не наблюдается зависимости времени компиляции от опции оптимизации.