Какую разрядность переменных, лучше выбирать в случае когда "а пофиг" ?
Например флаг, который может быть 0 или1, максимум -1, или считающий до 10 счетчик, и тому подобное, когда можно и u8, и s8, и u32б и s32.
Памяти-то в Кортексах обычно более чем достаточно, и экономить нужно не всегда, но влияет-ли это на быстродействие программы?
Есть ли разница для локальных и глобальных переменных, и для volatile?

Спасибо.

Дайте пожалуйста, ссылку, где вы усмотрели write-back cache (впрочем как и иные виды кеша) в M3 кортексах

Если Вы потрудитесь открыть например "Cortex-M3 Technical Reference Manual", то тоже сможете усмотреть.
Например в разделе Bus Interface\Write buffer:

Да и вообще в куче мест, если воспользуетесь поиском по "cache".
Например ещё в MPU.

PS: К тому-же кеш может быть не в ядре M3, а периферии конкретного МК, например в его External Memory Interface.

PPS: А интересно, уважаемый DASM, у вас не возникала мысль "зачем вообще нужны команды типа DMB/DSB если кеша нет"?

Уточню, есть ли он в однокристаллках all-in-one, типа STM32F405 . Внешние памяти ,как ни крути, вешают на более серьезное, А9 и выше


Не возникло, наличие команды еще не означает наличие соответствующего железа. These ARM and 32-bit Thumb instructions are available in ARMv7 ( http://infocenter.arm.com/help/index.jsp?t...c/CIHGHHIE.html ), а про Кортексы М3 пишут, что у них вообще нет кеш-контроллера
Хотя с другой стороны про M3 написано "The processor implements the ARMv7E-M architecture profile." Короче непонятно мне.

Вообще-то топик не про какой-то конкретный проц, а про M3/M4 вообще. И советы соответственно - касабельно всех M3/M4.
На шине эти сигналы есть и если в STM32F405 кеша нет - это только его личная беда.

И насчёт внешней памяти Вы ошибаетесь. Зачем тогда интерфейсы внешней памяти присутствуют в M3/M4-ядрах?
Например LPC1778/LPC1788, STM32F429....

Может и ошибаюсь.

В M3 и M4 кэша нет. Цитата из книги Ю:
PLD Pre-load data. This is a hint instruction typically use for cache memory to
accelerate data accesses. However, since there is no cache inside the
Cortex-M3 and Cortex-M4 processors, this instruction behaves as NOP.


Если просто заполнение, то байтами, сгруппированными по 4, заполнить будет почти в 4 раза быстрее, чем словами. Но если еще что-то делать с байтами, то вряд ли. Впрочем, для массивов важнее экономить память, чем скорость, так что и выбора-то в данном случае не может быть.

В ядре нету. Но может присутствовать в МК, построенных на этом ядре. А в ядре есть вся поддержка для этого.

Не очень понимаю смысл кеша, расположенного на внешней памяти. Или в ядре со сверхбыстрым доступом, или он не нужен вообще. Тогда уж покупать лицензию на М3 и городить СОЗУ для кеша. Но вроде речь про серийные камни.

Все поняли вопрос?

Т.е. ограничений ни по размеру, ни по быстродействию нет, ибо "пофиг".
Ограничения по быстродействию или по размеру тут не обсуждается.
Насколько я понял, ТС просит "default type", когда выбор не очевиден и не играет роли.
Осмелюсь предположить, что в данном случае самым сильным критерием будет переносимость (в рамках M3/M4).
Очевидно, переносимость между компиляторами, средами, библиотеками и т.п.

А как же разгонять медленный флешь? Ведь вся соль применения CM3-4 именно в исполнении кода из FLASH на скорости не уступающей RAM. А без разного рода кешей этого бы не было. DSB я использую в реальных проектах (в обработчиках некоторых прерываний) и без этой инструкции программа была бы не так лаконична и вообще бы не работала (проверено).

Ну да. Я могу и в третий раз повторить ответ.
Тут ведь вопрос стоит слишком глобально. Если говорить о аргументах функции, возвращаемых ей значениях, отдельных счётчиках или флагах, то наиболее переносимым вариантом является uint_fast8_t. В остальных случаях надо смотреть по задаче.

Об этом я забыл. Да и по жизни не приходилось использовать.

Вот именно.
В целом правильно uintXX_t, но где значения не имеет, int, надо полагать достаточен.

Я везде (а это получатся только M3/M4/M0) int и пишу.
Для остальных случаев пользуюсь "своими" BYTE, WORD и DWORD - соответственно 8, 16, 32 бита (без знака).
Но это не правило, т.к. я программист-одиночка и работаю на себя.
Что там компилятор наоптимизирует для меня на порядок менее важно, т.к. в критических случаях заставляю "молотить" периферию, а не софт.

То бишь "пишу непереносимые приложения" ..

Это с какой стороны посмотреть...
В своих проектах копипасту практикую чуть более чем полностью. Все при этом переносится.
С хорошим чужим кодом не работал. Свой код тоже никому отдавать не собираюсь.
И... ранее я предупреждал, что

Может, не от хорошей жизни я не использую стандартные C-библиотеки (в т.ч. и stdint).
Сейчас, вроде, нет никаких оснований их не использовать,но как-то... страшно.
Все работает, а я тут трогать начну...

Нет, не совсем так.
Я наверное не очень ясно выразился.
Под "пофиг" - имелось ввиду две вещи:
1) переменная типа флага, или считающего до 10 счетчика. Ее можно разместить и в байте и в ворде и в инте.
2)что памяти в этих процах как правило, более чем достаточно, и экономить ее используя именно байт - смысла нет, если это не дает каких-то других преимуществ.
А вот быстродействие как раз очень даже интересовало.
В общем, я понял что за исключением каких-то специальных случаев, юнитов, структур и больших массивов - надо не морочить себе голову и использовать u32,s32,vu32,vs32.
А тем более для локальных переменных.