Особенно с учетом того, что эту функциональность в той или иной степени все равно пришлось бы реализовывать самому, что скушало бы примерно половину этого объема, если не больше.

Что-нибудь да скушало бы, это точно. Вообще, стремлюсь пользоваться самыми самыми простыми и "шоколадными" сервисами Delay, Stop, Resume, Cooperate, а в прерываниях не использую сервисы как класс (расставлю флажки и потом подбираю их в цикле планировщика). Конечно, это минимум возможностей, и хоть ясно как сделать все это без RTOS, делать без нее категорически не хочется. Даже если удастся 100-200 байт "освободить".

Во-первых оптимизирующий компилятор заменяет switch на переход по таблице...

Во-вторых суть switch (вместо альтернативы с таблицей адресов *функций*) в том, что ограничивается, на уровне языка, область видимости переменных/функций на уровне ближайшей функции-автомата, а не на уровне модуля. Практически табличный подход может оказаться более неэффективным из-за исключительно нерациональной, например, передачи аргументов и локальных переменных автомата.




Сопрограмммы, увы, существенно отстают даже от SWITCH технологии им. А. А. Шалыто. Последняя, впрочем,
самодостаточна только для простых систем.

IAR AVR не так давно имел 3!!! модели работы со switch. Устанавливается ручками. Ведёт себя соотвественно - специально проверял.

Дело в том, что сопрограммы в представленном формате фактически только статические. Область видимости ограничивается сутью - локальные переменные статические. Область видимости - соответственно.

О так называемой "технологии им Шалыто" унал от создателя nesos - http://www.nilsenelektronikk.no/nenesos.html - о чём давал линк на первой странице обсуждения в 14-м посте.
А насчёт сопрограмм, то они, конечно, имеют свои недостатки. Вот господин Adam Dunkels сопрограммы ввернул в Protothreads и не постеснялся. Покажите, плз. внятный академический пример, в котором SWITCH сделан не на виртуальном языке, а на Си (но не nesos) и как его применить и чем же оно так разительно отличается. Хочу увидеть практический вариант SWITCH технологии явно отличающийся от статических сопрограмм. А то получается "армянин лучше, чем грузин"

Я то думал, что суть switch - обеспечить нужную логику работы
Если сравнивать switch и массив функций с вызовом по индексу по удобству работы программиста (считая компилятор идеально оптимизирующим), то я пришел к простому выводу - если switch помещается на экран (страницу), то использую switch, если нет - массив функций, специальным образом их называя. Сложности передачи аргументов не убедительны.
Что же касается RTOS... При значительно отличающихся приоритетах задач мне лично хочется иметь механизм управления ресурсами простым и наглядным.

Во-первых, хороший оптимизирующий компилятор это делает не всегда, а только
тогда, когда это выгодно....
Красиво расказываете....,
а нельзя ли какой нить примерчик в студию ?
то есть типа исследование того как разные компиляторы раскрывают switch..case по сравнению
с табличным вызовом... было бы очень интересно...

...а чем RTOS не конечный автомат? Ведь автомат это набор состояний и правил перехода между состояниями, а RTOS как раз неплохой набор "кубиков" для реализации автомата, потому что любая задача (в рамках ОС) может быть приостановлена при выполнении в состояние которое определяется разработчиком и перейти в другое состояние по какому-либо событию (сообщение, сигнал, семафор).





...не понимаю. Как правило этот механизм и есть простой и наглядный, при этом описывается в нескольких правилах.

Вот перевод упомянутой здесь статьи о конечных автоматах - Martin Gomez "Embedded State Machine Implementation".

могу посоветовать вот это http://www.state-machine.com кооперативная и приоритетная реализация + графическая среда разработки. Мне нравится.

Во блин, не заметил что тема нафталином пропитана