Интерактивный компилятор для embedded. Интересно, хоть что-то похожее есть? Вот есть некий проект на С. Кучка файлов. Будем рассматривать варианты, когда проект небольшой, но и требуемый размер кода тоже маленький, либо есть небольшой кусок проекта, который критичен по размеру и (или) скорости - в TCM засунуть, или в 256 байт 51 однокристалки :).
Варианты, когда "все влезает и успевает" трогать не будем. "Не мешай, пусть работает" (С).
Натравливаем компилер на наш кусок. И визуализирум результат в специальной среде, где удобно:
* редактировать код
* сопоставлять его с выходом компилера (чтобы прямо в редакторе отображалось, отредактировал - оно быстро перекомпилировалось)
* делать сравнение метрик получившегося результата при разных опциях компилера
* расширенные настройки процесса компиляции.
Как вариант - собрать кусок со всеми возможными вариантами оптимизации компилера, прогнать на симуляторе, подсчитать такты и байты памяти, решить, что лучше для задачи.
Важно, что это небольшой кусок, его компилировать в 100 вариантах и прогонять на симуляторе займет немного времени.
Код обработчика прерывания, код DSP, работы с таймером, АЦП, etc. - самое то, а вот с IP стеком так извращаться едва ли стоит.
"расширенные настройки процесса компиляции" - это:
* управление использованием регистров - в пределах нашего куска, возможно, стоит изменить стандартное распределение регистров. Возможно, это даст выигрыш даже с учетом дополнительных пересылок на границах куска
* отнесение переменной к разным классам памяти - в 51, например, есть разница между 256 байтами ОЗУ и всем остальным ОЗУ, и для этого служат разные команды (если не перепутал). Когда разных команд нет, это решается на уровне линковки, конечно.
* всякие тонкие опции оптимизации.
Да, это потребует особой структуры компилятора, но для мелких чипов результат может быть очень хороший.
По сравнению с чисто ASM кодингом, вся работа, которую компилер берет на себя, так и останется на его стороне, и экономия времени будет большая. А тонкая настройка выделенных кусков снимет сам вопрос необходимости ASM кодинга.
Самокритика.
* Привязка к версии компилера - полная. Тонко подстроенный код будет собираться только на конкретной версии. В принципе, при использовании нормального инструментария иметь на машине кучу версий и подверсий компилера - не проблема.
* концепция модульного и независимого инструментария распадается - компилер, линкер, библиотекарь уже не сами по себе. Здесь уже потребуется некая глобальная надстройка по планированию проекта, распределению ресурсов и проч.
* теряется универсальность компилера. Так у нас есть великий и могучий GCC (в совокупности со всеми прибамбасами), который и для embedded, и для линуха, и для венды собирает. А так для embedded получается свой компилер - что, в принципе, оправдано - см. IAR
Еще критика, примеры, контрпримеры?
-
- И зачем ? с маркетинговой точки зрения лучше взять кристалл помощнее с некоторым запасом на будущее... и быстрее выпустить продукт, чем заниматься утрамбовыванием с негарантированным и непрогнозируемым исходом-выходом ?!? как задачка для кафедры sav6622(80 знак., 20.07.2017 23:40)
- Вижу 2 области применения. Evgeny_CD(1407 знак., 21.07.2017 00:12, ссылка)
- И зачем ? с маркетинговой точки зрения лучше взять кристалл помощнее с некоторым запасом на будущее... и быстрее выпустить продукт, чем заниматься утрамбовыванием с негарантированным и непрогнозируемым исходом-выходом ?!? как задачка для кафедры sav6622(80 знак., 20.07.2017 23:40)