State_Maschine

Здравствуйте, Orlov!

Hе надоело еще идиотом прикидываться? Вам там что, заняться больше нечем?

Всего Вам Ольга

У пациента жестокий бред. Практически вся документация GNU написана понятным языком. В отличии от MSDN, например, где язык вроде и английский, но какой-то исключительно непонятный, и вообще "воды" много.

Где реальный проект?

У пациента белая горячка. Время там всегда, для каждой ветви, конечное и одинаковое. И очень даже предсказуемое. Можно по тактам посчитать в листинге...

Речь идёт не о времени switch-case, а о том, что оно всё в цикле, пока добежит до нужного автомата -- оборот в несколько десятков миллисекунд. Почему так долго -- а потому, что бесполезные проверки условий (и отнюдь не switch-CASE), которые никогда (почти) не выполняются. Например, проверки состоянийх других автоматов. Т.е. налицо отсутствие эффективного механизма взаимодействия между автоматами. Почему я и предлагаю организацию механизмов аналогичных используемым в типично планировщике многозадачной/многопоточной ОС. Т.е. проверку условий, например, заменить на сигнализацию семафором.

Здравствуйте, Уважаемый Slav!

Fri Jul 07 2006 16:16, Slav Matveev wrote to Olga Nonova:

ON>> ... (см. мой пример хранения кода состояния в ON>> регистре порта вывода).

SM> хотелось бы взглянуть на реальный проект, где код состояние SM> хранится в регистре порта в/в, и как это можно перевести SM> на предложенный (*f)();

Для мелкоконтроллеров я этого еще не делала. Собственно и пытаюсь выяснить, как такое можно было бы заделать средствами С. Однако, для ПЛИСов реализация сабжа прямо на ножках выводв- это классика.

SM>>> что бы, например process->getstatus() вернул константу, SM>>> а не абстрактное 0x12345678.

ON>> Вы ведете речь о распределенных в сети процессах? Или, все-же о ON>> поцессах внутри одного девайса с одним микроконтроллером?

SM> Я веду речь о многозадачной среде.

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

ON>> В последнем случае, наиболее эхотажном, никто не запрещает ON>> передавать символьные имена функций и конечных автоматов между ON>> модулями обычной директивой extern.

SM> и линковать "на лету" ?

Зачем? Все происходит на этапе сборки проекта.

SM>>> работает через call и приводит к необходимости сохранять- SM>>> восстанавливать окружение.

ON>> Обращаю внимание- происходит вызов процедур без параметров, которые ON>> также ничего не возвращают. Приличный компилятор поймет, что ON>> "сохранять- восстанавливать окружение"- излишнее занятие.

SM> хоть с параметрами, хоть без них, но извольте SM> во-1 выделить место под локальные переменные, SM> во-2 сохранить регистры, используемые для локальных переменных SM> вызывающей функции.

Hет в сабже никаких локальных переменных, не нужны они. Или С-компилятор обязательно вставит? Hо, это уже претензии к авторам компилятора.

ON>> "do_something" не обсуждается, т.к. одинаково в любом случае.

Обсуждается время ветвления сабжа по состояниям. Сколько оно?

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Slav!

Fri Jul 07 2006 16:16, Slav Matveev wrote to Olga Nonova:

ON>> .... (см. мой пример хранения кода состояния в ON>> регистре порта вывода).

SM> хотелось бы взглянуть на реальный проект, где код состояние SM> хранится в регистре порта в/в, и как это можно перевести SM> на предложенный (*f)();

Вспомнила! Видела у Phillips-а пример решения конечного автомата для ихнего варианта I2C. Там статус-регистр I2C использовался напрямую в качестве младшего байта адреса ветвления. Старщий назначался принудительно в свободной странице кодов. Все это, естественно, на ассемблере (Metalink). Интересно, как бы такое же реализовать на С ?

Всего Вам Хорошего Ольга

Посмотрим как у вас заглючит, если пинг -- больше секунды...