a = b; a = c; это не кривой код, но без явного указания что с этим делать оптимизатор испортит логику.
Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".
Если же предположить что: a,b,c имеют тип int (int a,b,c;), то этот код соответствует коду: a = c и компилятор его нормально скомпилит. Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?
Работа кода с оптимизатором и без всегда будет отличаться, притом в зависимости от настроек оптимизатора и код при этом не будет кривой. Отличия могут привести к неправильной работе.
Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой. Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).
Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".
В случае разных типов я бы указал приведение к типу. Его тут есть?
Цитата:
тот код соответствует коду: a = c и компилятор его нормально скомпилит. Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.
Цитата:
Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой. Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).
Сдаюсь. Тратить время на поиски глюков оптимизатора не хочу. Когда попадётся очередной, если не забуду - покажу Вам персонально. Новый и используемый всеми компилятор безгрешен. Логика его безупречна. В любом ином случае - кривой код или компилятор старый и никем не используется... Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.
Откройте для себя такое ключевое слово: "volatile".
По поводу INT или FLOAT, в первой строчке программы, для первых трех переменных. Изначально было так: Потом у меня из - за отсутствия скобок, ничего не работало, и я для исключения кажущейся ( для меня ) причины просто изменил размерность первых трех переменных до FLOAT. В счетчик кол.ва циклов, в десятичную переменную со знаком ( -2 147 483 648,0 : 2 147 483 647,0 ) сохраняем значение переменной с такой же разрядностью + переменная, но со максимальным значением не более 300. Т.е. логично использовать для этих целей переменную размерности INT ( - 32 768 : 32 767 ). Всего получается 16 проходов цикла. Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT. jcxz, что вы имели в виду ? Спасибо.
Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно. Пишите так чтобы код был как можно оптимальнее, иначе потом придется переучиваться или будете писать медленный и ресурсоемкий былокод. Можете посмотреть сколько тактов нужно МК без без аппаратной поддержки float для вычислений с плавающей точкой. http://purebasic.mybb.ru/viewtopic.php?id=717
Использование float не делает из кода "быдло". Количество тактов не является приоритетом. Не учите тупым шаблонам. Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы. Использование float чревато лишь из-за способа представления данных, в результате которого в отсутствие чёткого понимания механизма, может быть, например, неверное сравнение в условии. То, что числа с плавающей точкой обрабатываются дольше - всего лишь особенность, каковых куча.
Что-то он там не то для H750 намерял, как может получиться в полтора раза меньше F4... У меня для 480 MHz вышло 16 тактов вместо 26, а для 240 MHz, когда делитель AHB можно единичным сделать, вообще всего 11 тактов.
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту.
Для этого есть volatile. Если вам нужно именно это, то нужно описать: int volatile a, b, c; (это опять к слову о том - зачем описывать что такое a,b,c) И тогда будет работать именно так. Без volatile - как я описал выше. Если человек имел виду такой алгоритм, но написал как вы привели (без volatile) - код кривой, а написатель его - сам себе дурак. Как я уже говорил. И дело не в компиляторах/оптимизаторах, а в написателе сего недоразумения. Впрочем - у неумех всегда во всём инструмент виноват.
Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.
Баги компиляторов есть, я же не отрицаю (и даже сам их находил и не один). Но в 99.99% случаев кривизна работы какого-то кода - заслуга не кривого компилятора, а прослойки между стулом и клавиатурой. А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду. Так как - чем выше уровень оптимизации - тем труднее сопоставить исходный код, результирующей последовательности асм-команд. Если какие-то неумехи используют эти опции всегда (так как не умеют писать код, корректно работающий с любым уровнем оптимизации), то это говорит только об их уровне компетенции. А нормальный программист если видит, что при включении максимальной оптимизации, програмамма стала глючить, начинает искать ошибки в своём коде. А не заметает проблему под ковёр, отключая оптимизацию. Второе - признак быдлокодера, а не программиста.
Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT. jcxz, что вы имели в виду ?
Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность. А значит на 16-м шаге значение fahr будет: fahr = lower + step * 16 + delta * 16 delta будет зависеть от особенностей реализации операций FPU в данном конкретном компиляторе/МК, а также - от фазы Луны (delta может быть больше или меньше 0). А значит в каких-то случаях у вас будет 16 шагов, а в каких-то - 15 шагов.
Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы.
А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего? Вот это и называется быдлокод - скомпилили одним компилятором - 16 проходов, другим - 15. Конечно виноват компилятор и не быдлокодер!
А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего?
Читайте внимательно:
Цитата:
Использование float чревато лишь из-за способа представления данных, в результате которого в отсутствие чёткого понимания механизма, может быть, например, неверное сравнение в условии.
Это я написал. Поставить сюда ржущий смайлик, что ли...
Цитата:
А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду.
Понятно. Но я уже говорил - спорить не буду. Не видите очевидного, сами себе противоречите (volatile - то же опция) - Ваше счастие. Да и куда мне, неумехе-то, у которого инструмент виноват. У меня даже понимание термина "алгоритм" другое. Неверное.
Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно.
С точки зрения скорости выполнения и громоздкости, float в том коде не самое страшное. Гораздо хуже то, что там ещё есть и double-операции. Их даже и не всякий ARM аппаратно осилит, а уж о STM8 - вообще молчу.
Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту. ---------- К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?
Последний раз редактировалось sergey.UA Пт янв 08, 2021 17:36:29, всего редактировалось 1 раз.
Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту.
Тут дело не в точности. Корректно написанное ПО должно выполняться одинаково при работе в любом окружении и компиляции любым компилятором. А у вас будет зависеть от реализации FPU и от особенностей работы его режима округления. Поэтому типы с плавающей точкой используют только там, где это реально нужно. Для счётчика цикла они не нужны и даже вредны. И при операциях сравнения типов плавающей точки использовать операции ==, <=, >= следует осторожно, помня о погрешности и применяя вместо == проверку на диапазон. Также следует избегать алгоритмов с накоплением ошибки вычислений (как у вас, где на каждом шаге цикла ошибка вычислений delta суммируется).
К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?
Нет таких команд в языке си. Как и функции - это не элементы языка.
PS: Вы бы лучше сперва учебник по си до конца дочитали, прежде чем что-то писать.
Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.
Не всегда. Если число дробное, то зависит от числа, а целые числа float может хранить без погрешности вплоть до 24-х бит, так что при шаге 20 можно столкнуться с проблемами не раньше 838861 прохода
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения