no comment




1. А что? Дорого? Зато может способствовать уменьшению количества функций

2.Например, для повышения уровня языка реализации до проблемно-ориентированного  http://www.citforum.ru/internet/xml/graphml/

Возможно, я не совсем понятно выразился - Gomez забивает не всю таблицу переходов автомата, а только одномерный массив jump table, указателей на функции состояний. Там в самом начале листинга можно ее увидеть.
В любом случае это не дает преимуществ по сравнению с прямым присвоением:


Преимущества: работает быстро, фактически как вычисляемое GOTO
Недостатки: требует стек для вызова функций, при реализации в прерываниях вызова по ссылке компилятор обычно сохраняет весь контекст, это долго и требует много стека.

По поводу объема: в 8-битных процессорах если указатель занимает 2 байта, то каждое присвоение требует 2 команды ассемблера. Соответственно для автомата на 50 состояний и 150 переходов потребуется 300 команд в ПЗУ (600Б для AVR), для switch с переменной состояния типа char потребуется 300Б ПЗУ на переходы, для Gomez-технологии потребуется 300Б на переходы и 100Б на jump_table, итого 400Б. Для 16-ти и 32-х битных объем switch и присвоения указателей практически одинаков, а для Gomeza все равно дополнительно требуется место для jump table.


1. За счет чего? C использованием switch вообще одна функция.
2.Обычно проблему снаала описывают, а потом реализуют.

если еще есть интерес, могу продолжить про реализации...

Наверное, jumptable может быть полезен для сохранения текущего состояния в eeprom и восстановления после сбоя. Пишем лишь индекс, а не потенциально
опасный указатель.

Интерес есть!

Вот мои небольшие наблюдения на смежную тему кооперативной многозадачностиhttp://electronix.ru/forum/index.php?showtopic=59333

сомнительно. все равно потом по указателю функция вызывается,
для таких случаев обычно пишут лог переходов в том или ином виде, ну и список разрешенных переходов (собственно, он у Гомеса есть).

реализовать кооперативную многозадачность с помощью конечных автоматов - собственно, этим я хотел закончить про реализации.

Недостатки прямого присваивания значения переменной состояния, типа
в том, что при большом количестве ветвлений можно случайно пропустить присваивание.
Одним из методов контроля на этапе компиляции является следующий:
функция состояния возвращает значение следующего состояния


кроме некоторого контроля за присваиванием, такой подход не дает никаких премуществ.
Просто на практике не всегда бывает возможно обеспечить полноту тестов.

Индекс проще проверит на валидность. Всего лишь на максимум.
Индекс удобно использовать при генерации события по смене состояния.
Индекс удобно использовать для возврата в старое состояние.

Кароч, я использую индексы и массивы функций. Иногда двумерный массив functions[state][event] в каком-нить менюшном сервисе.

Внутри программируемой логики собирают микропроцесоры и пишут для них программы.
На микроконтроллерах пишут программы эмулирующие логику(конечные автоматы).
Походу использовать компоненты по назначению сегодня не модно.
Или просто грани стираются, и будущее за гибридными технологиями.
Скоро наверно будем делать проэкты для одного кристалла из пары сотен операционников, нескольких микроконтроллеров, и массива программируемой логики.

с первым согласен. Только какой смысл в такой проверке? Проверка в рантайме - от какого бага она спасает? Если на этапе отладки - использование только поименованных констант не позволит вызвать неописанное состояние. С другой стороны, где гарантия, что индексы идут подряд.
со вторым и третьим - не могу ничего сказать. Не могли бы вы написать пример реализации поподробнее? Для одномерного и двумерного массива? Особенно, для functions[state][event], что является индексом массива?

я считаю, что удобство понятие не только субъективное.
Удобно - когда логическая ошибка проявляется как можно раньше. Например, на этапе компиляции (стоимость обнаружения)
Удобно - когда при введении нового состояния его надо прописывать как можно в меньшем количестве списков (связность). И компилятор следит за правильностью (стоимость).
Неудобно - когда в нескольких списках описание состояния должно быть с одинаковым номером (связность).


насколько я знаю, в 70-х годах было мнение, что наиболее перспективная парадигма в программировании - автоматный подход.
"Лучше забивать молотком шурупы, чем закручивать отверткой гвозди"

В некоторых случаях смысл есть. Например, после ресета можно вернуться в нужную точку. Делал прибор, который, зараза, был чувствителен к ESD. Вот и пришлось решать проблему программно.



Да все тупо...

Весь смех в том, что сишная или иная ЯВУ-программа при помощи переменной state эмулирует счетчик команд целевой машины. Вот эта некузявость порядком раздражает.  

Я давно предлагал любителям обратить внимание на вычисляемый goto в гнусе.

Тада, и я это предложение даже проиллюстрировал уже
http://electronix.ru/forum/index.php?showt...mp;#entry520130
и парой постов дальше с массивом и индексом.

LOL : чуть дальше "Но реально не применяю :-), как-то не жмёт пока обычный switch()... "

Вот и меня не жмет. А switch или таблица - это вопрос качества монитора и разрешения
Если все case не помещаются на два-три экрана, то лучше бить на таблицу. Если помещаются, то лучше помолиться за IAR, который при оптимизации ту же таблицу сам нарисует.

Пример взят из реальной задачи - нужно было при каждой смене состояния сохранять
его во внешней eeprom, чтобы восстановить при пропадании питания. Лог переходов писать смысла нет, так как не важно, каким путем мы попали в данное состояние - важен сам факт попадания.
Индекс - один байт, пишется атомарно. При загрузке легко его проверить на попадание
в диапазон разрешенных состояний. Если будет восстановлено неверное состояние,
неприятно, но не так разрушительно как вызов функции по неверному указателю.
Еще одна особенность - прошивка могла быть обновлена, и обработчики
могли бы лежать на других адресах.