Оптимальный тип переменной для ARM, философский вопрос... Опции

[Dog Pawlowa]

Как-то привык на 8 и 16-разрядными контроллерами не использовать больше, чем нужно.
При работе с ARM экономить нет смысла по большому счету, если только не массивы.
Логично?
А что с заимствованным кодом делать? Ручками переделывать там, где быстродействие критично?

[meister]

Как-то привык на 8 и 16-разрядными контроллерами не использовать больше, чем нужно.
При работе с ARM экономить нет смысла по большому счету, если только не массивы.
Логично?
А что с заимствованным кодом делать? Ручками переделывать там, где быстродействие критично?

Если код правильный - на этот случай там должны быть типы как size_t, diffptr_t и указатели.

[_Pasha]

При работе с ARM экономить нет смысла по большому счету, если только не массивы.
Логично?

Пользоваться типами stdint.h: uint8_t, uint_fast8_t etc


Причем, чем раньше (на этапе проектирования) возникнет вИдение, где надо именно 8/16/32 бит, а где чтоб проц не ложился от неоптимальных операций - тем меньше переделывать. Заимствованный код как правило не обладает такой прозорливостью

[KRS]

Если использоватьС99
то как сказал _Pasha использовать uintX_t uint_fastX_t
но есть один ньюанс
для хранения в памяти использовать _fast не оптимально - выгрыша в производительности нет, а пямять будет расходоваться больше.
Поэтому для локальных переменных (которые могут располагаться в регистрах) использовать fast, а для памяти обычные типы. И работать с переменными - загружать в локальную _fast, обрабатывать и сохранять в память, тогда код оптимальный будет. ( и на 8ми разрядном тоже)

[_Pasha]

но есть один ньюанс

Почему только один? Любой ввод-вывод - сплошные ньюансы. Поля структур, которые, в принципе, могут полететь во внешний мир, будь то файл или пакет - туда уж точно fast и least не лезут

[Dog Pawlowa]

Поля структур, которые, в принципе, могут полететь во внешний мир...

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

[Rst7]

Похоже, у иаровцев шило в этом месте, не могут не поменять формат от версии к версии.

Ну перейти на ELF-формат объектников - это правильный ход со стороны IAR'овцев. Под шумок и формат скриптов поменяли. Но это не смертельно - в принципе, разбираться там часа два, не больше.

[KRS]

Эти массивы структур переложить бы в SDRAM, так и тут нужно с конфигурацией линкера разбираться.
Похоже, у иаровцев шило в этом месте, не могут не поменять формат от версии к версии.

так у них XCL формат уже давнооо не менялся. А в 5.x ARM они вынуждены были его сменить из-за ABI. Зато теперь можно разными компилерами компилить и линкерами разными собирать ( только напильником обработать некоторые места, проблемы с библиотеками вылезут, но если какой то исходник не использует библиотек его можно скомпилировать другим компилятором)

[Rst7]

По теме. В любом случае выгоднее грузить и выгружать в память переменные пачками. Иногда даже разбирать в рукопашную считанную из памяти в регистр 32хбитную переменную на байтовые и преобразовывать их в размер регистра перед использованием, а после использования склеивать обратно и сохранять. Но это уже настолько врукопашную, что я даже не знаю, могут ли такие приземленные материи интересовать философов

[Dog Pawlowa]

Но это уже настолько врукопашную, что я даже не знаю, могут ли такие приземленные материи интересовать философов

Нет, конечно, мы смотрим на звезды!
Сейчас пока быстродействие некритично, но не весь GUI прописан, может еще что вылезет.

Но чтобы ставить красивые заплаты на свой и чужой код, учту