Для небольшой программы большая часть размера определяется библиотеками / DLL, от которых зависит ваша программа. Поскольку вы ссылаетесь на ARM / Freescale / Pic, я предполагаю, что вы имеете дело с компактными встроенными приложениями, в которых размер данных измеряется в байтах, а не в мегабайтах.
Для вашего собственного кода разница в размере будет определяться:
- размер слова (т.е. 32-битные программы имеют тенденцию быть немного больше / больше данных, чем 8-битные)
- (т.е. код Intel в сравнении с ARM, freescale, PIC)
В вашем случае я ожидаю, что PIC является наиболее важной частью (для ограничений RAM / ROM). Таким образом, достаточный мониторинг размера компиляции PIC во время разработки ПК является достаточным. Выход компоновщика будет содержать информацию о размере TEXT / DATA / BSS, которую вы можете отслеживать.
Обычно я работаю над встроенными системами. В моей работе большая часть размера данных известна во время разработки (то есть количество буферов * размер буфера). Что касается размера кода, у меня есть практические правила для разных архитектур, которые помогают мне проверять работоспособность во время разработки. Например, я определяю набор некоторых библиотек существующего кода, для которых я знаю номера производительности и размера для каждой архитектуры. Таким образом, я знаю, какое соотношение я могу ожидать во время разработки. Если программа для ПК содержит 1 МБ данных, она не помещается в 8-разрядный PIC .....