nedoPC.org

Тут ОС для AVR помещали. Здорово конечно. Но я в последнее
время заразился принципиально более другим подходом -- автоматным
программированием. ОС не нужна. Все "задачи" или "процессы"
в терминах ОС реализуются как конечные автоматы. Система
параллельных задач -- не что иное как система взаимодействующих
параллельных автоматов. Автоматы могут взаимодействовать по
вызываемости, по обмену номерами состояний, с помощью бинарных
сообщений. Автоматы могут быть вложенными в состояния других
автоматов, и таким образом организовывать сложную иерархию
в рамках одного автомата.

Нет, на самом деле практически всё позаимствовано из работ А. А. Шалыто (см. http://www.softcraft.ru) Технология была опробована на практике, показала свои недостатки и определённые преимущества. В первую очередь -- чрезвычайно низкое число логических ошибок, их практически не было. Получилась достаточно надёжная система. Из недостатков можно отметить относительную сложность программирования и проектирования автоматов с большим числом состояний, сложность программирования вычислительных задач. Ещё из недостатков особенно заметна заметная "тормознутость" системы. Есть и определённые решения направленные на исправление отмеченных недостатов. В целом, я считаю, подход показал себя удачно и будет, я думаю, развиваться, по крайней мере мной, и дальше.

Важно, что техника программирования применимая к "классическому"
программированию применима и к автоматному программированию --
всё может описываться в рамках системы автоматов.

Считаю, что многозадачной операционной системой нового поколения могла бы являться ОС созданная для поддержки работы системы параллельных автоматов-задач. Где любая системная (драйвер, например) или прикладная задача описывается конечным автоматом,
динамически встраиваемым в систему. А языки программирования,
например язык C или ассемблер, расширен библиотеками для поддержки автоматного программирования. Особенно это важно,
возможно, для микропроцессорных устройств с небольшим объёмом
памяти, где зачастую практически невозможно разместить в ОЗУ стек для более чем двух-трёх параллельных задач (против нескольких десятков автоматов -- ведь практически вся память, выделяемая для работы автомата на каком-либо шаге освобождается по завершению его работы).

Хотелось бы адаптировать бы switch-технологию, исключить громоздкий оператор switch, заменить его, например, на функции-состояния. Реализовать библиотечную поддержку автоматного программирования часто встречающимися примитивами. Особенно что касается ввода-вывода -- стандартные библиотечные
функции явно преусматривают блокировку. Реализовать автомат-планировщик для эффективного запуска функций-состояний согласно приоритетами и только для функций-состояний действительно в этом нуждающих, чтоб не тратить понапрасну время на проверку заведомо ложных условий. Это, отчасти, может реализоваться с помощью механизма бинарных сообщений и автомата-диспетчера, регистрирующего смену состояний автоматов, переменные состояний которых участвуют в условиях переходов других автоматов.

Интересно, а практикует ли кто тоже такой подход к программированию. Речь не идёт о win-программировании
(Я НЕНАВИЖУ БИЛДЕР!), а о программировании встраиваемых микропроцессорных систем, напрямую связанных с реальным железом.

А можно попросить дать какую-нибудь обзорную статью по теме ? Многовато там текста, не ясно с чего начинать.

У нас с ним коллеги встречались недавно - говорят выдающейся странности человек

У нас на американской работе были попытки использовать автоматную реализацию алгоритмов. Результат - программа достаточно быстро превращается в совершенно нечитабельное месиво из обработчиков состояний - без специального тула так программировать нельзя. А относительно программирования микроконтроллеров - в любой книжке для чайников всегда имеется хотя бы один пример программирования микроконтроллера в терминах state machine.