Comments 12
Выглядит как С++, а не С.
Было бы неплохо данные автоматы промоделировать в Stateflow и сгенерить из них Си-код. Я уверен, что там можно получить код и пооптимизированей.
Я уверен, что там можно получить код и пооптимизированей.
но на чём основана эта уверенность? было бы неплохо хотя бы общие соображения.
Основана на использовании.
Из общих соображений — генератор кода не ограничен какими либо парадигмами программирования, как программист. Например, читаемостью кода. Поэтому он может не меняя исходного представления автомата состояния, его читаемости и функционирования провести множество оптимизаций. Как примеры:
- Заменить if, then, else — switch case и наоборот, где это приведет к уменьшению размера кода или изменению его эффективности
- Убрать из кода состояния и переходы, которые не могут произойти по определению. Компилятор на такое не способен.
- Убрать условия, которые не будут проверяться или всегда истинны/ложны
- Заменить простые автоматы состояний, функции и переходы таблицами истинности.
- Применить, в зависимости от заданных критериев, inline функции — т.е. заменить вызов функции ее полным кодом или наоборот. Применить макросы, где это эффективно.
- выбрать соответствующие типы переменных, которые наилучшим образом отвечают критериям оптимизации для конкретной процессорной архитектуры (т.к x86, ARM, TMS320 и 8051 немного по-разному переваривают char, unsigned long и пр.)
- развернуть или нет циклы for в зависимости от критериев.
- и кучу других оптимизаций
Например, читаемостью кода.
Читаемость кода как таковая не влияет на быстродействие — оптимизируется не исходный код, а программные структуры.
— Если вы читали внимательно, на рис 15 я показал насколько алгоритмы поддаются всему, что вы описали. коэффициент оптимизации получился 1.15, то есть, проделав все описанные вами пункты, оптимизатор смог улучшить результат всего на 15%.
— я embedder с большим стажем, и долгое время писал проги, и обязательно изучал во что они превращаются после компиляции. Я как супернейросетка выработал такое профессиональное чутьё, что можете положиться на моё слово — я могу построить по диаграмме состояний на самом деле высокоэффективный код, при этом вполне осознавая, какой исполняемый код получится. Это не хвастовство, я просто хочу сказать, что вы можете вполне доверять тому что я пишу
— Если вы читали внимательно, на рис 15 я показал насколько алгоритмы поддаются всему, что вы описали. коэффициент оптимизации получился 1.15, то есть, проделав все описанные вами пункты, оптимизатор смог улучшить результат всего на 15%.
Я так понимаю, что вы использовали компиляторные оптимизации o1, o2, o3, наверное. Это немножко не то, так как применимость данных оптимизаций ограничена исходным кодом, который им вскормлен. Оптимизации, же, которые делает генератор кода, работают на один уровень выше — на этапе генерации самого кода. Поэтому тут совсем другой уровень и результат.
Я сам применял компиляторные оптимизации и к сгенерированному коду и к ручному и говно-коду и получал те же самые 15% во всех случаях, поэтому могу констатировать, что прирост производительности благодаря им мало зависит от исходного кода.
я embedder с большим стажем, и долгое время писал проги, и обязательно изучал во что они превращаются после компиляции. Я как супернейросетка выработал такое профессиональное чутьё, что можете положиться на моё слово — я могу построить по диаграмме состояний на самом деле высокоэффективный код, при этом вполне осознавая, какой исполняемый код получится. Это не хвастовство, я просто хочу сказать, что вы можете вполне доверять тому что я пишу
Ничуть не пытаюсь приуменьшить вашу квалификацию. Просто по моим наблюдениям качество автоматически сгенерированного кода из автоматов на сегодня настолько высоко, что позволяет состязаться с ембеддерами с большим стажем. Причем, чтобы нарисовать такой автомат, необязательно иметь опыт ембеддерщика вообще, а достаточно иметь базовое понимание, как работают автоматы вообще.
Я сам применял компиляторные оптимизации и к сгенерированному коду и к ручному и говно-коду и получал те же самые 15% во всех случаях, поэтому могу констатировать, что прирост производительности благодаря им мало зависит от исходного кода.
не соглашусь. В следующей статье я последовательно пишу исходник и делаю комиты по шагам. Там в первом, «лабораторном», неоптимальном варианте, оптимизация 10 кратная.
Это немножко не то, так как применимость данных оптимизаций ограничена исходным кодом, который им вскормлен. Оптимизации, же, которые делает генератор кода, работают на один уровень выше — на этапе генерации самого кода. Поэтому тут совсем другой уровень и результат.
генерил в IAR visualSTATE их простые примеры. По крайне мере там, ничего не говорит даже о приблизительной оптимальности по сравнению с ручным. Просто совершенно другой уровень. Я не делал там свой пример, но речь может идти о в десятки раз менее эффективном коде. Там сама схема реализации автомата такая, что можно не генеря давать прогнозы.
Ну и вообще мое ИМХО насчет эволюции разработки программных автоматов для встраиваемых систем — это графическое моделирование и автоматическая генерация кода. Рисуете Вашу блок-схему с переходами и состояниями так, как она должна работать. Моделируете с внешними воздействиями и отлаживаете у себя на компьютере. Потом нажимаете на кнопку и генерируете либо Си-код для микроконтроллера, либо VHD/Verilog для ПЛИС, если автомат должен реагировать за наносекунды. Компилируете и получаете рабочий автомат с первого раза. Если надо, выбираете галочки и оптимизируете автомат по скорости, занимаемому месту и требуемой памяти.
Рисуете Вашу блок-схему с переходами и состояниями так, как она должна работать.
тут вопрос в степени детализации блок-схемы и в том руководствуясь чем, собственно, вы будете её рисовать. автоматное программирование — не столько способ реализации, потому что, как я показал в этой статье — автоматная реализация — дело нехитрое, а вопрос проектирования и я это постараюсь показать в следующем цикле — практикуме
Ну и вообще мое ИМХО насчет эволюции разработки программных автоматов для встраиваемых систем — это графическое моделирование и автоматическая генерация кода.
если вам будет так удобней, то пожалуйста, автоматное программирование в моём представлении весьма демократично. В предыдущей статье есть глава «Артефакты автоматной схемотехники» и там показано, что бывает удобней просто написать функцию в «естесственном» программистком стиле, она останется автоматно реализованной.
Пожалуйста Вам IDE, ядро которого скомпилировано в среде LabView на конечных автоматах, является одновременно кодогенератором и софт контроллером, там же и вариант интерфейсной абстракции. При этом понятие автоматное программирование там продемонстрировано в виде Switch Technology, которая берет свое начало от в.у.
На автоматное программирование можно смотреть как на метод, а можно и как на ее функциональные инструменты. Настройка алгоритма происходит вербальным образом и симуляцией кодогенератора.
Автоматное программирование. Часть 4. Эффективность автоматно-спроектированных программ