Petrovich (05.07.2018 14:15, просмотров: 1) ответил sladkoejka на а зачем его volatile делать, если это локальная переменная и никто кроме локального кода её менять не может?-
- в чём сложность? Кстати, проверил под симулятором. Оба варианта (с INC R6 и без него) работают одинаково и дают абсолютно одинаковую задержку. Что с volatile, что без. Но с volatile задержка в 2.28 раза больше. При этом вариант, где код начинается sladkoejka(79 знак., 05.07.2018 14:42)
- Вот по этоой статье учились поколения :) Petrovich(58 знак., 05.07.2018 14:50,
)
- Ничего нового в этой статье нет. Насчет использования volatile в циклах - это очень неудачный совет. Лучше использовать какое-либо полезное действие в теле цикла (например NOP). И вот почему. sladkoejka(1041 знак., 05.07.2018 15:02 - 15:06)
- Сравнивайте Bill(3498 знак., 05.07.2018 16:24)
- Что сравнивать? В вашем примере ошибка - вы закоментили вызов __no_operation(). Без этого вызова цикл должен быть удалён. То, что с volatile не удаляет - это результат плохой оптимизации. Мозгов у компилятора не хватает чтобы отследить, что sladkoejka(667 знак., 05.07.2018 17:19)
- Я не о зависаниях. Я - о недостаточной "сообразительности" компилятора. - Bill(05.07.2018 18:04)
- "То, что с volatile не удаляет - это результат плохой оптимизации" 0men(471 знак., 05.07.2018 17:36)
- Прочитайте вашу цитату из стандарта внимательнее. В ней речь идёт об "объекте, который может быть модифицирован". В случае-же с локальной переменной volatile, никто её модифицировать не может, время её жизни ограничено временем выполнения функции. sladkoejka(420 знак., 05.07.2018 18:09 - 18:13)
- Вы не до конца перевели фразу. 0men(320 знак., 05.07.2018 18:21)
- Тут не фантазия, а логика. Если код ничего не делает и ни на что не влияет, то его можно удалять и никакие volatile в этом коде этому не помеха. В стандарте речь идёт о случаях, когда такое удаление может повлиять на наблюдаемое поведение. - sladkoejka(05.07.2018 18:36)
- не надо собственной ущербной логикой заменять строгие требования стандарта :-)) - =AlexD=(06.07.2018 08:10)
- поциент слился - SciFi(06.07.2018 08:47, ссылка, ссылка)
- Я не вижу смысла с вами спорить. Насчёт volatile указателей пример я вам привел. Продублирую и тут: sladkoejka(887 знак., 06.07.2018 15:07 - 15:15)
- Кстати у тебя скорй всего компилятор ещё та паделка: fk0(571 знак., 07.07.2018 00:11)
- Замени на extern volatile int x и сразу оптимизация пропадёт. - fk0(07.07.2018 00:09)
- обдурить оптимизатор можно, т.к. он не все случаи анализирует, но от этого код не становится оптимальным... - sladkoejka(07.07.2018 10:59)
- Keil C 8051: Bhg2(1600 знак., 06.07.2018 15:18)
- Я не вижу смысла с вами спорить. Насчёт volatile указателей пример я вам привел. Продублирую и тут: sladkoejka(887 знак., 06.07.2018 15:07 - 15:15)
- поциент слился - SciFi(06.07.2018 08:47, ссылка, ссылка)
- весь смысл volatile в указании невозможности для компилятора определить, могут затрагивающие эту переменную оптимизации повлиять на поведение или не могут. - AlexG(05.07.2018 19:00)
- не надо собственной ущербной логикой заменять строгие требования стандарта :-)) - =AlexD=(06.07.2018 08:10)
- Тут не фантазия, а логика. Если код ничего не делает и ни на что не влияет, то его можно удалять и никакие volatile в этом коде этому не помеха. В стандарте речь идёт о случаях, когда такое удаление может повлиять на наблюдаемое поведение. - sladkoejka(05.07.2018 18:36)
- Это фантазии, ничего подобного там не написано. Вы что-то прочитали между строк? - SciFi(05.07.2018 18:11)
- это не фантазии, а то что написано в стандарте. Читайте внимательнее, вы видите "may be modified in ways unknown to the implementation or have other unknown side effects"? Локальная переменная ограничена областью видимости по стандарту и никому sladkoejka(248 знак., 05.07.2018 18:23)
- Тогда было бы написано так: "An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. When that is the case, any expression referring to such an object shall be SciFi(131 знак., 05.07.2018 18:27)
- Тем не менее, компиляторы удаляют код volatile указателей на не volatile данные, которые были удалены оптимизатором. И такое поведение признано соответствующим стандарту. Однако в вашей интерпретации такое удаление недопустимо, т.к. указатель sladkoejka(24 знак., 05.07.2018 18:50)
- Ссылку в студию. Если от объекта берётся адрес, и он реально используется, не надо удалять такой объект. - SciFi(05.07.2018 19:41)
- Вам лень открыть компилятор и попробовать? Почему я должен это делать за вас? sladkoejka(121 знак., 06.07.2018 15:03)
- Нещитово. Приведение к типу volatile - это совсем не создание объекта типа volatile. Попробуйте так: int x = 123; int *volatile y = &x; y = y; - SciFi(06.07.2018 15:11)
- Попробовал - результат тот-же самый, компилятор полностью удаляет код, вместе с объектом указателя, помеченного как volatile. См. скриншот. Дальнейшие изыскания предлагаю проводить самостоятельно. sladkoejka(06.07.2018 15:21)
- Вы попробовали не тот код, который я написал. Зачем так делать? Ну и, согласно информации по ссылке, это таки вражеский компилятор. SciFi(726 знак., 06.07.2018 15:36, ссылка)
- В вашем примере происходит модификация данных помеченных как volatile. Компилятор в этом случае не может быть уверен, что эту модификацию данных никто не увидит и она ни на что не повлияет. Поэтому код удалять не будет. sladkoejka(06.07.2018 15:48 - 15:53)
- Как пример, чтение внешней памяти может использоваться для сброса сторожа - замешивается на дешифраторе адрес и строб RD, а с выхода получаем сигнал сброса. Если указатель на volatile, то компилятор не должен оптимизировать обращение. Хотя Vit(261 знак., 06.07.2018 16:24)
- тут тоже согласен, для контроллеров это критично, поэтому даже чтение через volatile указатель удалять не стоит. Однако если volatile помечена локальная переменная, не являющаяся указателем, то её можно удалять. Т.к. хранится локальная переменная sladkoejka(95 знак., 06.07.2018 18:14)
- тут тоже согласен, для контроллеров это критично, поэтому даже чтение через volatile указатель удалять не стоит. Однако если volatile помечена локальная переменная, не являющаяся указателем, то её можно удалять. Т.к. хранится локальная переменная sladkoejka(95 знак., 06.07.2018 18:14)
- Дык в этом весь смысл и есть - отключается оптимизация обращения к данным помеченным как volatile, если же к ним обращения нет, то код вполне может выпиливаться. - =AlexD=(06.07.2018 16:01)
- Как пример, чтение внешней памяти может использоваться для сброса сторожа - замешивается на дешифраторе адрес и строб RD, а с выхода получаем сигнал сброса. Если указатель на volatile, то компилятор не должен оптимизировать обращение. Хотя Vit(261 знак., 06.07.2018 16:24)
- В вашем примере происходит модификация данных помеченных как volatile. Компилятор в этом случае не может быть уверен, что эту модификацию данных никто не увидит и она ни на что не повлияет. Поэтому код удалять не будет. sladkoejka(06.07.2018 15:48 - 15:53)
- Вот в другом компиляторе ничего не удаляется даже в вашем первом примере Bhg2(31 знак., 06.07.2018 15:26, ссылка)
- все компиляторы не обязаны производить максимальную оптимизацию. Каждый оптимизирует по своему. Но компилятор имеет полное право удалять такой код при оптимизации. Это соответствует стандарту. - sladkoejka(06.07.2018 15:28)
- Кстати, еще есть небольшое уточнение : Bhg2(345 знак., 06.07.2018 16:04)
- volatile указатель - это для компилятора данные. Инициализация такого указателя требует модификации данных. А если указатель помечен как volatile, то компилятор ограничен в выводах может ли такая модификация на чтото повлиять или не может. Поэтому sladkoejka(430 знак., 06.07.2018 16:30)
- С точки зрения даже абстрактной машины, локальная переменная - это переменная в памяти, а не в регистре. Нет никаких таких регистров в языке Си. А volatile обозначает именно внешние побочные эффекты в памяти. Всё, финита. Никакие =AlexD=(76 знак., 06.07.2018 16:46)
- В порядке уточнения. Переменные могут быть размещены в регистрах, для этого существует специальный квалификатор класса памяти - register. Только по-моему, современные компиляторы его игнорируют. Или нет? - Bill(06.07.2018 18:20)
- это просто рекомендация компилятору хранить переменную в регистре. Компилятор может её не придерживаться. - sladkoejka(06.07.2018 18:29)
- Соглашусь, но это действительно только при условии, что код модифицирует данные данные через volatile указатель. Через указатель можно изменить любую ячейку памяти, которая доступна другому коду. А если не модифицирует, то на данные никак не sladkoejka(40 знак., 06.07.2018 18:03 - 18:11)
- В порядке уточнения. Переменные могут быть размещены в регистрах, для этого существует специальный квалификатор класса памяти - register. Только по-моему, современные компиляторы его игнорируют. Или нет? - Bill(06.07.2018 18:20)
- С точки зрения даже абстрактной машины, локальная переменная - это переменная в памяти, а не в регистре. Нет никаких таких регистров в языке Си. А volatile обозначает именно внешние побочные эффекты в памяти. Всё, финита. Никакие =AlexD=(76 знак., 06.07.2018 16:46)
- volatile указатель - это для компилятора данные. Инициализация такого указателя требует модификации данных. А если указатель помечен как volatile, то компилятор ограничен в выводах может ли такая модификация на чтото повлиять или не может. Поэтому sladkoejka(430 знак., 06.07.2018 16:30)
- Строго говоря, цитате из стандарта не соответствует. SciFi подметил верно. Но здравому смыслу соответствует. Я за такую оптимизацию. Но тут нужно быть осторожным, это отступление от буквы стандарта. Огромное спасибо за примеры! - Nikolay_Po(06.07.2018 15:33)
- А в чём собственно несоответствие? Я считаю все соответствует. В цитате оговаривается случай, когда переменная может быть кем-то модифицирована и это может привести к изменению наблюдаемого поведения. В данном-же случае, даже если ктото изменит sladkoejka(39 знак., 06.07.2018 15:41)
- Согласен, что в стандарте слишком кратко сказано. Тема приведения к volatile не раскрыта. Есть, однако ещё один официальный документ "обоснование", там эта тема затрагивается, и яр нарушает то, что там написано. Впрочем, они могут притвориться SciFi(67 знак., 06.07.2018 16:12, ссылка)
- Здесь Nikolay_Po(217 знак., 06.07.2018 15:55)
- А в чём собственно несоответствие? Я считаю все соответствует. В цитате оговаривается случай, когда переменная может быть кем-то модифицирована и это может привести к изменению наблюдаемого поведения. В данном-же случае, даже если ктото изменит sladkoejka(39 знак., 06.07.2018 15:41)
- Кстати, еще есть небольшое уточнение : Bhg2(345 знак., 06.07.2018 16:04)
- все компиляторы не обязаны производить максимальную оптимизацию. Каждый оптимизирует по своему. Но компилятор имеет полное право удалять такой код при оптимизации. Это соответствует стандарту. - sladkoejka(06.07.2018 15:28)
- Вы попробовали не тот код, который я написал. Зачем так делать? Ну и, согласно информации по ссылке, это таки вражеский компилятор. SciFi(726 знак., 06.07.2018 15:36, ссылка)
- Попробовал - результат тот-же самый, компилятор полностью удаляет код, вместе с объектом указателя, помеченного как volatile. См. скриншот. Дальнейшие изыскания предлагаю проводить самостоятельно. sladkoejka(06.07.2018 15:21)
- Нещитово. Приведение к типу volatile - это совсем не создание объекта типа volatile. Попробуйте так: int x = 123; int *volatile y = &x; y = y; - SciFi(06.07.2018 15:11)
- Вам лень открыть компилятор и попробовать? Почему я должен это делать за вас? sladkoejka(121 знак., 06.07.2018 15:03)
- Ссылку в студию. Если от объекта берётся адрес, и он реально используется, не надо удалять такой объект. - SciFi(05.07.2018 19:41)
- Тем не менее, компиляторы удаляют код volatile указателей на не volatile данные, которые были удалены оптимизатором. И такое поведение признано соответствующим стандарту. Однако в вашей интерпретации такое удаление недопустимо, т.к. указатель sladkoejka(24 знак., 05.07.2018 18:50)
- читайте до конца - или иметь другие неизвестные побочные эффекты - 0men(05.07.2018 18:25)
- локальная переменная доступна только внутри тела функции и только на время её выполнения. Если эта функция ничего не делает и никак не влияет на данные доступные другому коду, её можно спокойно удалять вместе со всеми volatile локальными sladkoejka(174 знак., 05.07.2018 18:32)
- фраза про побочные эффекты означает, что разработчик лучше знает, что делать компилятору. Компилятору нужно ничего не трогать. Стандарт об этом прямо говорит. Все ваши разделение на локальные и глобальные это только ваши фантазии, в стандарте 0men(22 знак., 05.07.2018 18:46)
- не нужно ничего выдумывать. Логика стандарта проста. Если объект никому не доступен, его можно удалять для оптимизации, т.к. это никак не повлияет на поведение системы. volatile действует только на данные, которые могут быть кому-то потенциально sladkoejka(65 знак., 05.07.2018 18:56)
- Это ты просто рафинированный программист, который тупо смотрит на код, и делает какие-то свои выводы, исходя из абстрактной вычислительной системы в вакууме. В реальной жизни у микропроцессора есть всякие там шины памяти, кеши, ПДП и пр. вещи, =AlexD=(486 знак., 06.07.2018 08:23 - 08:48)
- Строго говоря, компилятор действует в рамках абстрактной вычислительной машины. Для него важно чтобы наблюдаемое поведение соответствовало указанному в программе. Эффективность кэширования его не волнует. Конечно при условии, что это не повлияет sladkoejka(67 знак., 06.07.2018 16:04)
- бред, ты вообще не понял что тебе говорят. Если компилер будет выкидывать volatile, то половина тестов железа просто перестанут работать. Этого никто не допустит ни в теории, ни на практике. - =AlexD=(06.07.2018 16:37 - 16:40)
- тест, у которого результат не зависит от того что он делает никому нафик не нужен. Такой тест можно смело удалять. А если результат есть и зависит от удаления переменной, то такая переменная оптимизации не подлежит. - sladkoejka(06.07.2018 18:37 - 18:39)
- Пффффррр, мля, ну ты даёшь. Да почти все тесты измеряют ВРЕМЯ, и им вообще не нужен никакой результат :-))) , либо результат с точки зрения ЯЗЫКА бессмысленен, например проверка памяти через запись-чтение. - =AlexD=(16.07.2018 10:28)
- тест, у которого результат не зависит от того что он делает никому нафик не нужен. Такой тест можно смело удалять. А если результат есть и зависит от удаления переменной, то такая переменная оптимизации не подлежит. - sladkoejka(06.07.2018 18:37 - 18:39)
- бред, ты вообще не понял что тебе говорят. Если компилер будет выкидывать volatile, то половина тестов железа просто перестанут работать. Этого никто не допустит ни в теории, ни на практике. - =AlexD=(06.07.2018 16:37 - 16:40)
- Строго говоря, компилятор действует в рамках абстрактной вычислительной машины. Для него важно чтобы наблюдаемое поведение соответствовало указанному в программе. Эффективность кэширования его не волнует. Конечно при условии, что это не повлияет sladkoejka(67 знак., 06.07.2018 16:04)
- А чё спорить-то, сделайте иначе бомж(178 знак., 05.07.2018 22:49)
- Ну да, конечно, восьмой gcc: fk0(64 знак., 06.07.2018 09:03)
- :-))) - SciFi(06.07.2018 09:59)
- гениально :) - sladkoejka(06.07.2018 03:08)
- Ну да, конечно, восьмой gcc: fk0(64 знак., 06.07.2018 09:03)
- Интересное вышло обсуждение. Ранее не задумывался, но мне близка позиция Сладкоежки. Эффект от исполнения кода наступает лишь в двух случаях: Nikolay_Po(1136 знак., 05.07.2018 22:11)
- Не надо ничего выдумывать. Читайте текст стандарта. Компиляторостроители читают именно его. - SciFi(05.07.2018 22:13)
- логика стандарта совсем иная - если переменная имеет квалификатор volatile, то действия с этой переменной не подлежат оптимизации и должны быть представлены кодом как есть. Ни каких слов про доступнай, область видимости и жизни в стандарте нет - 0men(05.07.2018 19:00)
- Это ты просто рафинированный программист, который тупо смотрит на код, и делает какие-то свои выводы, исходя из абстрактной вычислительной системы в вакууме. В реальной жизни у микропроцессора есть всякие там шины памяти, кеши, ПДП и пр. вещи, =AlexD=(486 знак., 06.07.2018 08:23 - 08:48)
- не нужно ничего выдумывать. Логика стандарта проста. Если объект никому не доступен, его можно удалять для оптимизации, т.к. это никак не повлияет на поведение системы. volatile действует только на данные, которые могут быть кому-то потенциально sladkoejka(65 знак., 05.07.2018 18:56)
- фраза про побочные эффекты означает, что разработчик лучше знает, что делать компилятору. Компилятору нужно ничего не трогать. Стандарт об этом прямо говорит. Все ваши разделение на локальные и глобальные это только ваши фантазии, в стандарте 0men(22 знак., 05.07.2018 18:46)
- локальная переменная доступна только внутри тела функции и только на время её выполнения. Если эта функция ничего не делает и никак не влияет на данные доступные другому коду, её можно спокойно удалять вместе со всеми volatile локальными sladkoejka(174 знак., 05.07.2018 18:32)
- Тогда было бы написано так: "An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. When that is the case, any expression referring to such an object shall be SciFi(131 знак., 05.07.2018 18:27)
- это не фантазии, а то что написано в стандарте. Читайте внимательнее, вы видите "may be modified in ways unknown to the implementation or have other unknown side effects"? Локальная переменная ограничена областью видимости по стандарту и никому sladkoejka(248 знак., 05.07.2018 18:23)
- Вы не до конца перевели фразу. 0men(320 знак., 05.07.2018 18:21)
- Прочитайте вашу цитату из стандарта внимательнее. В ней речь идёт об "объекте, который может быть модифицирован". В случае-же с локальной переменной volatile, никто её модифицировать не может, время её жизни ограничено временем выполнения функции. sladkoejka(420 знак., 05.07.2018 18:09 - 18:13)
- Что сравнивать? В вашем примере ошибка - вы закоментили вызов __no_operation(). Без этого вызова цикл должен быть удалён. То, что с volatile не удаляет - это результат плохой оптимизации. Мозгов у компилятора не хватает чтобы отследить, что sladkoejka(667 знак., 05.07.2018 17:19)
- компилятор НИКОГДА не удалит цикл с volatile переменной. Более того, он никогда не соптимизирует такой цикл - 0men(05.07.2018 15:18)
- Ну уж нет. Если он удалит переменную volatile, то это будет вражеский компилятор (хотя всякие бывают, конечно). Но тут __no_operation() убирает необходимость в volatile, потому что __no_operation() "вызывает побочные эффекты", т.е. не может быть SciFi(72 знак., 05.07.2018 15:06)
- "Сделает" для delay - это оставит время выполнения похожим независимо от оптимизации. А без volatile декремент переменной цикла delay может быть выполнен кучей разных способов(и за разное время) при какой-нибудь галочке типа cross call Petrovich(14 знак., 05.07.2018 15:42, )
- ничего вражеского нет, в достаточно умных оптимизаторах такие вещи в порядке вещей. Если тело цикла пустое, а volatile переменную гарантированно никто не видит (нет возможности получить ссылку), то такой цикл можно спокойно удалять. Пользы от него sladkoejka(223 знак., 05.07.2018 15:19 - 15:22)
- На современном gcc не воспроизводимо. - fk0(06.07.2018 09:07)
- фантазёр - =AlexD=(06.07.2018 08:07)
- пример в студию - 0men(05.07.2018 15:19)
- "Сделает" для delay - это оставит время выполнения похожим независимо от оптимизации. А без volatile декремент переменной цикла delay может быть выполнен кучей разных способов(и за разное время) при какой-нибудь галочке типа cross call Petrovich(14 знак., 05.07.2018 15:42,
- Сравнивайте Bill(3498 знак., 05.07.2018 16:24)
- Ничего нового в этой статье нет. Насчет использования volatile в циклах - это очень неудачный совет. Лучше использовать какое-либо полезное действие в теле цикла (например NOP). И вот почему. sladkoejka(1041 знак., 05.07.2018 15:02 - 15:06)
- Вот по этоой статье учились поколения :) Petrovich(58 знак., 05.07.2018 14:50,
- в чём сложность? Кстати, проверил под симулятором. Оба варианта (с INC R6 и без него) работают одинаково и дают абсолютно одинаковую задержку. Что с volatile, что без. Но с volatile задержка в 2.28 раза больше. При этом вариант, где код начинается sladkoejka(79 знак., 05.07.2018 14:42)