ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
769951
Evgeny_CD, Архитектор (20.07.2017 23:30, просмотров: 879)
Интерактивный компилятор для embedded. Интересно, хоть что-то похожее есть? Вот есть некий проект на С. Кучка файлов. Будем рассматривать варианты, когда проект небольшой, но и требуемый размер кода тоже маленький, либо есть небольшой кусок проекта, который критичен по размеру и (или) скорости - в TCM засунуть, или в 256 байт 51 однокристалки :). Варианты, когда "все влезает и успевает" трогать не будем. "Не мешай, пусть работает" (С). Натравливаем компилер на наш кусок. И визуализирум результат в специальной среде, где удобно: * редактировать код * сопоставлять его с выходом компилера (чтобы прямо в редакторе отображалось, отредактировал - оно быстро перекомпилировалось) * делать сравнение метрик получившегося результата при разных опциях компилера * расширенные настройки процесса компиляции. Как вариант - собрать кусок со всеми возможными вариантами оптимизации компилера, прогнать на симуляторе, подсчитать такты и байты памяти, решить, что лучше для задачи. Важно, что это небольшой кусок, его компилировать в 100 вариантах и прогонять на симуляторе займет немного времени. Код обработчика прерывания, код DSP, работы с таймером, АЦП, etc. - самое то, а вот с IP стеком так извращаться едва ли стоит. "расширенные настройки процесса компиляции" - это: * управление использованием регистров - в пределах нашего куска, возможно, стоит изменить стандартное распределение регистров. Возможно, это даст выигрыш даже с учетом дополнительных пересылок на границах куска * отнесение переменной к разным классам памяти - в 51, например, есть разница между 256 байтами ОЗУ и всем остальным ОЗУ, и для этого служат разные команды (если не перепутал). Когда разных команд нет, это решается на уровне линковки, конечно. * всякие тонкие опции оптимизации. Да, это потребует особой структуры компилятора, но для мелких чипов результат может быть очень хороший. По сравнению с чисто ASM кодингом, вся работа, которую компилер берет на себя, так и останется на его стороне, и экономия времени будет большая. А тонкая настройка выделенных кусков снимет сам вопрос необходимости ASM кодинга. Самокритика. * Привязка к версии компилера - полная. Тонко подстроенный код будет собираться только на конкретной версии. В принципе, при использовании нормального инструментария иметь на машине кучу версий и подверсий компилера - не проблема. * концепция модульного и независимого инструментария распадается - компилер, линкер, библиотекарь уже не сами по себе. Здесь уже потребуется некая глобальная надстройка по планированию проекта, распределению ресурсов и проч. * теряется универсальность компилера. Так у нас есть великий и могучий GCC (в совокупности со всеми прибамбасами), который и для embedded, и для линуха, и для венды собирает. А так для embedded получается свой компилер - что, в принципе, оправдано - см. IAR Еще критика, примеры, контрпримеры?