не только.
a = b;
a = c;
это не кривой код, но без явного указания что с этим делать оптимизатор испортит логику.

С чего бы это? Он поступит точно исходя из того что за сущности из себя представляют a, b и с. От полного выкидывания кода до запуска МБР.

Он поступит так, как видел это программист, создававший его.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Нет, он поступит в соответствии со стандартом языка программирования.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Угу.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".

Если же предположить что: a,b,c имеют тип int (int a,b,c;), то этот код соответствует коду:
a = c
и компилятор его нормально скомпилит.
Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?

Добавлено after 10 minutes 55 seconds:

Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой.
Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).

В случае разных типов я бы указал приведение к типу. Его тут есть?

Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает 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 тактов.

Причём тут "приведение типа"?
Что такое a,b,c? Здесь форум для телепатов?
Предполагаю что это:
Соответствует вашему примеру? Да! Вы это имели в виду или что-то иное? Только телепат знает что имелось в виду. И как прикажете угадать нетелепатам?


Для этого есть volatile. Если вам нужно именно это, то нужно описать:
int volatile a, b, c; (это опять к слову о том - зачем описывать что такое a,b,c)
И тогда будет работать именно так. Без volatile - как я описал выше.
Если человек имел виду такой алгоритм, но написал как вы привели (без volatile) - код кривой, а написатель его - сам себе дурак. Как я уже говорил. И дело не в компиляторах/оптимизаторах, а в написателе сего недоразумения. Впрочем - у неумех всегда во всём инструмент виноват.

Баги компиляторов есть, я же не отрицаю (и даже сам их находил и не один). Но в 99.99% случаев кривизна работы какого-то кода - заслуга не кривого компилятора, а прослойки между стулом и клавиатурой.
А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду. Так как - чем выше уровень оптимизации - тем труднее сопоставить исходный код, результирующей последовательности асм-команд.
Если какие-то неумехи используют эти опции всегда (так как не умеют писать код, корректно работающий с любым уровнем оптимизации), то это говорит только об их уровне компетенции.
А нормальный программист если видит, что при включении максимальной оптимизации, програмамма стала глючить, начинает искать ошибки в своём коде. А не заметает проблему под ковёр, отключая оптимизацию. Второе - признак быдлокодера, а не программиста.

Добавлено after 9 minutes 6 seconds:

Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.
А значит на 16-м шаге значение fahr будет: fahr = lower + step * 16 + delta * 16
delta будет зависеть от особенностей реализации операций FPU в данном конкретном компиляторе/МК, а также - от фазы Луны (delta может быть больше или меньше 0).
А значит в каких-то случаях у вас будет 16 шагов, а в каких-то - 15 шагов.

Добавлено after 7 minutes 16 seconds:
Если float - в качестве счётчика цикла - делает.

А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего?
Вот это и называется быдлокод - скомпилили одним компилятором - 16 проходов, другим - 15. Конечно виноват компилятор и не быдлокодер!

Читайте внимательно:

Это я написал. Поставить сюда ржущий смайлик, что ли...


Понятно. Но я уже говорил - спорить не буду. Не видите очевидного, сами себе противоречите (volatile - то же опция) - Ваше счастие. Да и куда мне, неумехе-то, у которого инструмент виноват. У меня даже понимание термина "алгоритм" другое. Неверное.

А если написать например что-то типа:
Это быдлокод или "способ представления данных"?

Добавлено after 13 minutes 1 second:
С точки зрения скорости выполнения и громоздкости, float в том коде не самое страшное. Гораздо хуже то, что там ещё есть и double-операции. Их даже и не всякий ARM аппаратно осилит, а уж о STM8 - вообще молчу.

Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту.
----------
К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?

Тут дело не в точности. Корректно написанное ПО должно выполняться одинаково при работе в любом окружении и компиляции любым компилятором. А у вас будет зависеть от реализации FPU и от особенностей работы его режима округления.
Поэтому типы с плавающей точкой используют только там, где это реально нужно. Для счётчика цикла они не нужны и даже вредны. И при операциях сравнения типов плавающей точки использовать операции ==, <=, >= следует осторожно, помня о погрешности и применяя вместо == проверку на диапазон.
Также следует избегать алгоритмов с накоплением ошибки вычислений (как у вас, где на каждом шаге цикла ошибка вычислений delta суммируется).

Добавлено after 5 minutes 12 seconds:
Нет таких команд в языке си. Как и функции - это не элементы языка.

PS: Вы бы лучше сперва учебник по си до конца дочитали, прежде чем что-то писать.

Не всегда. Если число дробное, то зависит от числа, а целые числа float может хранить без погрешности вплоть до 24-х бит, так что при шаге 20 можно столкнуться с проблемами не раньше 838861 прохода

Мне вот так больше нравится.

в МЯЯЯЯУ. всё г... там.