Флоаты в STM32F303

[Eddy_Em]

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

[VladislavS]

Eddy_Em писал(а):

Код:

    SCB->CPACR = 0x0f << 20 ;  /* set CP10 and CP11 Full Access */

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

Код:

*((volatile uint8_t*)&SCB->CPACR+2) = 0xF0;

Добавлено after 1 minute 19 seconds:

Eddy_Em писал(а):

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

Главное это всё побыстрей на гитхаб выложить

[Eddy_Em]

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

[VladislavS]

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

Спойлер

111.png

(42.37 KiB) Скачиваний: 64

[Reflector]

AVI-crak писал(а):

Сравнение с оптимизированным и значительно ускоренным вариантом printf

Код:

rtt.println(1234.56768f);                                           // 1234.5676;       1338t
rtt.println(1234.56768f * 55555);                                   // 6.8586408E+07;   1674t
rtt.println(std::numeric_limits<float>::min());                     // 1.1754943E-38;   1768t

rtt.println(float_char(buff, 1234.56768f));                         // 1.234567626e3;   1429t
rtt.println(float_char(buff, 1234.56768f * 55555));                 // 6.8586408e7;     1302t
rtt.println(float_char(buff, std::numeric_limits<float>::min()));   // 1.175494352e-38; 1603t

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

[Eddy_Em]

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

[VladislavS]

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

[AVI-crak]

Разница есть, но вовсе не катастрофическая

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

[VladislavS]

Eddy_Em писал(а):

Ну и смысл?

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

Спойлер

usb.png

(43.97 KiB) Скачиваний: 47

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

[Reflector]

AVI-crak писал(а):

Кхм, откуда в три раза больше накапало M0 что-ли?

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

[jcxz]

VladislavS писал(а):

когда пойдут вызовы функций и прерываний, которые обрабатывает компилятор без моего участия? Если это действительно важно, то компилятор с ключом -mfloat-abi=hard должен сам это делать.

Компилятор это и делает. Попробуйте заглянуть в листинги:

Код:

char * GetStrByIxZ(char const *s, int ix)
{
        _Z11GetStrByIxZPKci: (+1)
 0xB538             PUSH     {R3-R5,LR}
 0x4604             MOV      R4,R0
 0x460D             MOV      R5,R1
 0xE003             B.N      ??GetStrByIxZ_0
  for (; --ix >= 0; s += strlen(s) + 1);
        ??GetStrByIxZ_1: (+1)
 0x.... 0x....      BL       strlen
 0x4420             ADD      R0,R4,R0
 0x1C44             ADDS     R4,R0,#+1
        ??GetStrByIxZ_0: (+1)
 0x1E6D             SUBS     R5,R5,#+1
 0x4620             MOV      R0,R4
 0xD5F8             BPL.N    ??GetStrByIxZ_1
  return (char *)s;
 0xBD32             POP      {R1,R4,R5,PC}
}

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

Добавлено after 3 minutes 53 seconds:

Eddy_Em писал(а):

VladislavS, вот делать мне нечего после каждого флоата букву f писать

И правда - не царское это дело!

[Reflector]

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

[VladislavS]

jcxz писал(а):

Сможете объяснить - зачем IAR это делает?

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

[Eddy_Em]

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

[AVI-crak]

Можно сделать write() виртуальной и это значительно ускорит работу RTT, при этом немного замедлит работу всего остального...

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

[Eddy_Em]

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

[Reflector]

Eddy_Em писал(а):

Вот засада!

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

А плеваться потом не будешь? Там USB только с кварцем работает, только при тактировании от 48/72 MHz и на USB нет встроенной подтяжки

Зато там есть флоаты и всякие ништяки по работе с аналоговой периферией.

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

AVI-crak писал(а):

Дык нужно быть честным в тестах, использовать голову с функцией заглушки - дабы измерить только скорость кода конкретной либы, а не всего что там вокруг.

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

[Eddy_Em]

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

[jcxz]

Reflector писал(а):

Касательно выравнивания стека на 8, насколько я знаю для M3/M4 оно не нужно

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

[Eddy_Em]

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