VladislavS, вот делать мне нечего после каждого флоата букву f писать, когда у компилятора флаг есть нужный!
Если у кого-то в компиляторе этого флага нет - его проблемы! Мне вообще наплевать на компиляторы кроме gcc!

Дарю минус несколько байт к размеру прошивки

Добавлено after 1 minute 19 seconds:
Главное это всё побыстрей на гитхаб выложить

VladislavS, чем твой вариант лучше обычного приравнивания? Все равно в итоге получается одно и то же: reg = x. У тебя выигрыша никакого нет, ладно бы, был МК 8-битный!..

Спорим на щелбан?

Спойлер

Вложение:

111.png [42.37 KiB]
Скачиваний: 117

Разница есть, но вовсе не катастрофическая, а по занимаемому месту скорее всего даже лучше получится...

VladislavS, по тактам абсолютно столько же. Ну и смысл?

Чудак человек. Димка бы за эти пару байт удавился и IDE сменил, а тебе всё равно. Эх, надо было на поджопник спорить, у тебя через неё лучше доходит.

Кхм, откуда в три раза больше накапало M0 что-ли?
Функции оптимизированы для M3, где есть умножение с 64b результатом. И полностью вырезано деление и плавающая точка из всех функций.
Скорость получается одинаковой для M3-M4-M7, A8 и так далее. Но на M0 ожидаемый провал.

У меня есть несколько прошивок, над которыми я глумлюсь когда настроение плохое. Сядешь, несколько байт, а то и десятков байт оптимизируешь и настроение улучшается. У меня USB-СDC уже утоптался до 1904 байт, из которых 408 это таблица векторов прерываний. И это без ущерба функционалу, само собой. Потом эти наработки в библиотеки и продакшен перекочёвывают. Вот с SCB->CPACR тоже перекочует.

Спойлер

Вложение:

usb.png [43.97 KiB]
Скачиваний: 99

ЗЫ: Вот сейчас смотрю на эту картинку, и вижу что инициализированных данных 0. Можно смело выкинуть из стартапа цикл копирования. Минус несколько десятков байт. Но это неспортивно будет уже.

Нет, на самом деле эта либа изначально писалась одним продвинутым товарищем на ассме как раз для M0(его либы прошиты в ROM для Pico), потому потенциально для M3 ее можно прилично оптимизировать, а для M0 она и так должна работать быстрее. Но вместе с ассмом были комменты на С по которым я восстановил код. А провал там много из-за чего... Во-первых, это все-таки функция форматированного вывода которой неявно передается "{g}" со всеми вытекающими накладными расходами. Во-вторых, у RTT довольно медленная функция write(), через которую работает put() выплевывающая по байту, но RTT нужен только в процессе отладки и на текущую скорость я не жалуюсь, а print() для Usart или Lcd работают быстро, т.к. в кольцевой буфер сильно быстрее чем по байту данные не добавишь, а дисплей вообще каждый символ сразу отрисовывает. Можно сделать write() виртуальной и это значительно ускорит работу RTT, при этом немного замедлит работу всего остального...

Компилятор это и делает. Попробуйте заглянуть в листинги:
IAR CM4F. Видим выравнивание стека на 8 (сохранение R3).
Сможете объяснить - зачем IAR это делает?
И так почти во всех функциях сохранение выравнено на 8. По-краней мере в тех, из которых есть вызовы других функций (так как компилятор предполагает, что внутри них выравнивание может быть нужно). В функциях из которых нет вызовов - там может и не будет выравнивать.

Добавлено after 3 minutes 53 seconds:
И правда - не царское это дело!

Касательно выравнивания стека на 8, насколько я знаю для M3/M4 оно не нужно, на M3 даже бит STKALIGN на одной ревизии отсутствует, на другой по умолчанию выключен, на третьей - включен. Это опция для совместимости со старшими ARM, аналогично есть инструкции исполняемые как NOP и существующие просто потому, что у других ARM они есть.

Идеи есть и они не сильно с FPU связаны. Можно же проверить, отключив в опциях проекта оный?

Мужики! Мне тут в ЖЖ товарищи подсказали наилучший перевод слова "быдлокод" на английский: "nigger-code"! Все, теперь реддит мой! =D

Ну я-же описал условия проверки быстродействия - функция заглушка, которая просто перебирает байты на фиксированный адрес. То-есть минимальная задержка с линейной зависимостью от размера сообщения.
Для средств печати текстовых сообщений, от каждой либы есть уникальный интерфейс, та самая голова - что торчит из хидера. В моём случае там набор костылей и одна голова printo(...). От официального printf -тоже табун костылей, но голова есно printf(...).
Дык нужно быть честным в тестах, использовать голову с функцией заглушки - дабы измерить только скорость кода конкретной либы, а не всего что там вокруг.

Вот засада!
Сел ковырять USB у STM32F303. Я-то думал, что это семейство больше на F072 похоже, а оказалось, что в нем вся гниль F103: нет внутренней подтяжки, всего лишь 512Б буфер (в принципе, с CAN можно будет поделить, абы CAN и USB одновременно работали, до CAN я еще не добрался), и, самое отстойное, нет HSI48! Япона ж мать! А я так надеялся, что без кварца можно будет работать…

У тебя точно провалы в памяти, процитирую посты годичной давности



Добавлено after 7 minutes 58 seconds:

Без особой разницы как мерять если интересует относительная разница в скорости. Printf медленнее твоей функции на почти 5000 тактов, а моя функцию на пару сотен, но она оптимизирована под M0, там можно задать формат и точность, сама по себе точность наверняка больше, а размер меньше. По большому счету даже правильность работы любительских функций форматирования для чисел с плавающей точкой под большим вопросом...

Reflector, там еще и у B/C всего лишь 256 байт на USB остается (т.к. CAN отжирает 256). Ну, в принципе, для CDC достаточно.
А память у меня плохая, да.

Тогда зачем IAR стек в функциях выравнивает? Просто так?
Речь про >=M4F. M3 не при чём.

У F303 еще косячок есть: организация памяти USB зависит от типа. У B и C всего 512Б на буфер, а адресация идет по схеме 1x16бит, а у D и E 1кБ на буфер, а адресация по схеме 2x16бит!
Вот же упоротые товарищи: даже внутри одного семейства реализация USB зависит от "крутости" чипа!