haker_fox 60 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 1 hour ago, Сергей Борщ said: у которых виноват компилятор Согласитесь, что иногда это так) Некоторые темы в подфоруме IAR красноречиво об этом говорят. Тут правда нужно обладать искусством отличить реально проблемы компилятора от "реально проблемы программиста". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 16 hours ago, inventor said: есть ли вообще смысл оптимизации Смотря по какому критерию опитимизировать: по скорости исполнения кода или по объёму этого самого кода. Ну и включив оптимизатор, и получив нерабочее решение, вы сразу же должны разобраться в проблеме, ибо она 100% есть! Оптимизатор НЕ меняет логику вашей программы, он лишь изменяет способ её подачи АЛУ процессора. Другими словами банальный цикл с Си может быть реализован в виде цикла на ассемблере, в виде линейного кода или компирования некого объёма памяти. Да, это разное время исполнениния кода и разный объём памяти, и да, здесь могут выплыть баги софта. Например, вы не анализируете флаг готовности результата АЦП (забыли, не усмотрели, не разобрались), а запускаете преобразование, и выполнив некий кусок кода, забираете готовый результат из регистров АЦП. И всё у вас работает прекрасно. Но как только вы включаете оптимизацию по скорости, ваш "медленный" неоптимизированный цикл начинает исполняться со скоростью света, и... результат из АЦП уже неправильный. Почему? А нет той задержки, необходимой для завершения преобразования. Кто виноват? Компилятор? Да, в первую очередь конечно он)))) Но немного подумав, и добавив опрос флага готовности АЦП или прерывание по завершению преобразования, вы выходите из зависимости компоновки кода, и по настоящему наслаждаетесь результатами работы оптимизатора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 7 hours ago, haker_fox said: Согласитесь, что иногда это так) Некоторые темы в подфоруме IAR красноречиво об этом говорят. Тут правда нужно обладать искусством отличить реально проблемы компилятора от "реально проблемы программиста". Я честно не видел ни одной темы тут где можно было бы однозначно говорить об ошибке компилятора. В многозадачных средах смена опции оптимизации приводит к изменению и ускорению последовательностей вытеснения. А в любом большом проекте на 100 тыс. строк и более попадаются финты с экономией на объектах синхронизации, поскольку это дорого по ресурсам процессора. Вот они то и вылазят когда последовательности вытеснения ложаться определенным образом. Я тут упоминал как то weird machines для взлома эксплуатирующие такой подход. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 30 минут назад, AlexandrY сказал: Я честно не видел ни одной темы тут где можно было бы однозначно говорить об ошибке компилятора. https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=147939 https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=148387 Случались баги и в предыдущих версиях. Только они случаются многократно реже, чем тут возникают сообщения типа "IAR опять глючит". И их наличие подтверждается куском си-кода + соответствующим ему результатом компиляции (асм), а не фразой типа "чё-то я тут написал и нифига не работает, видимо компилятор неправильно компилит". PS (по IAR-у): В последней версии (8.32.1) появился новый баг: ассемблер не понимает относительных путей для INCLUDE в асм-файлах. Например: INCLUDE ..\version.h - ошибка компиляции. Хотя раньше работало. Написал в поддержку. Сейчас они разбираются с этим. Как разберутся, напишу им по поводу https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=148387 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 17 часов назад, inventor сказал: речь шла оптимизации как таковой предыдущие ораторы накинулись на меня, назвав лохом что мол прога должна работать при любой оптимизации Давайте разделим вопрос на 2 связанных, но не тождественных части. Исходный код должен описывать поведение ПО в соответствии с нормами языка записанными, в случае С/С++, в тексте стандарта. Если это так, то корректно написанный компилятор, при любых опциях оптимизации (кроме тех которые явно не соответствуют стандарту) должен сгенерировать программу с поведением идентичным исходным кодам, мнению программиста, и тому что скомпилировано при других опциях оптимизации. Сложность С/С++ в том что ради возможности оптимизировать в текст стандарта введено понятие undefined behavior (детали опустим). Это тот случай когда синтаксически корректная программа является тем не менее некорректной. Так сложилось что без опций оптимизации такие некорректные программы тем не менее могут компилироваться в соответствии с представлениями программиста. Являются ли они от этого корректными? Правильный ответ - нет. Бывают ли проекты у которых в ридми записано, что они не могут быть собраны с высокими уровнями оптимизации? Да. Пока вы пишете сами для себя, никто вам плохого слова не скажет. Не первый и не последний програмист на С/С++, который не знает языка и работает на своих ошибочных представлениях о том как всё работает. Чем плох такой подход. Проблема в том что если к примеру прошивка перестанет влезать во флеш или к примеру понадобится больше быстродействия. В этом случае включение оптимизации приводит неработоспособному (и это в лучшем случае явно неработоспособному) коду. И выловить такие ошибки можно только вдумчивым дебагом в ассемблере программистом уровнем выше. Долго и дорого в общем. Вторая проблема что если исходник кто-то переиспользует, то и в бОльшем проекте придется отказаться от оптимизации. Естественно что человек хоть раз сталикивается с такими проблемными исходниками, без всякого преувеличения, начинает ненавидеть авторов, которые так пишут. С чем вы собственно здесь и столкнулись. А мораль проста, оптимизации помогают отловить некорректные участки кода в тот момент когда вы его только написали, что сужает область поиска ошибки с размером проекта до размера кода между двумя комитами. Что позволит выявить UB на стадии когда это не стоит астрономических трудозатрат. Так что вы вообще можете не использовать оптимизацию кроме как средство диагностики ошибочного кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 34 minutes ago, jcxz said: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=147939 https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=148387 PS (по IAR-у): В последней версии (8.32.1) появился новый баг: ассемблер не понимает относительных путей для INCLUDE в асм-файлах. Например: INCLUDE ..\version.h - ошибка компиляции. Хотя раньше работало. Написал в поддержку. Сейчас они разбираются с этим. Как разберутся, напишу им по поводу https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=148387 На это вы уже ссылались. Это не баги. Не будем переливать из пустого в порожнее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 10 минут назад, AlexandrY сказал: На это вы уже ссылались. Это не баги. Не будем переливать из пустого в порожнее. Да ладно? А если всё-таки дать себе труд прочитать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 16 minutes ago, Kabdim said: Бывают ли проекты у которых в ридми записано, что они не могут быть собраны с высокими уровнями оптимизации? Да. Вот тут бы ссылочку на такой ридми, и я бы поверил всем остальным вашим словам. А так извините..., многое противоречит моей практике. Спокойно брал дистрибутивы FreeRTOS, uC/OS, MQX, mbed ... компилировал с максимальной оптимизацией и всегда все прекрасно работало. Если и были проблемы в BSP то решались в течении пары дней. Что за маргинальные такие неуловимые проекты с невозможность максимальной оптимизации тут упоминаются никак в толк не возьму. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба Поделия партнеров. У вас, уж извините, НДА не подписан, так что ссылок и цитат не будет. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 11 minutes ago, jcxz said: Да ладно? А если всё-таки дать себе труд прочитать? Я читал. Там половина поток сознания, остальное фрагментарные наблюдения без систематических тестов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 1 минуту назад, AlexandrY сказал: Я читал. Там половина поток сознания, остальное фрагментарные наблюдения без систематических тестов. Скажите правду: "Читал и ничего не понял". Там приведены конкретные си-строки и участки кода в которые они компилируются, в которых происходит ошибка. Т.е. - всё предельно разжёвано. Но если даже так не понятно, то... больше говорить не о чем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба Если заметили я там участвовал в одном из обсуждений и доказал что это не баг, а проблема писателей софта. Но увидел однако что вы недостаточно сами исследовали обнаруженный вами эффект. При таком отношении не вижу смысла спорить с вашими выводами. Обнаружили и на том спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 1 час назад, AlexandrY сказал: Если заметили я там участвовал в одном из обсуждений и доказал что это не баг, а проблема писателей софта. Т.е. - то что при выполнении операции над 16-битными данными, компилятор пропустил команду расширения их до 32 бит (UXTH) и обработал как 32-битные данные, с соответственно неверным результатом - это проблема писателей софта? Да уж.... Больше нет слов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psyhologic 0 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба Язык предоставляет возможность (инструмент), от программиста зависит как эту возможность использовать. Соответственно от уровня программиста будет зависеть насколько красиво/ужасно применены оптимизации, как разрешены зависимости, сохранена ли кроссплатформенная переносимость кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 4 декабря, 2018 Опубликовано 4 декабря, 2018 · Жалоба 4 hours ago, jcxz said: Там приведены конкретные си-строки и участки кода в которые они компилируются, в которых происходит ошибка. Есть ли в таких случаях переходить на другой компилятор, например Keil? Про GCC молчу, ибо они все такие разные... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
