Возражений нет. Для более подробного ознакомления можно посетить
http://reflex-language.narod.ru/

"Язык Рефлекс, известный также под именем "Си с процессами", ориентирован на программирование управляющих алгоритмов в промышленной автоматизации и робототехнике: для систем, предполагающих активное взаимодействие с внешней средой, технологическим оборудованием, физическими процессами через датчики и органы управления."

А вопросы такие:
1. История возникновения языка - год, автор, от кого произошел, ...
2. Users Manual на сам язык (по примеру на сайте можно понять, но тяжело
3. Кратко - 10 отличий от IEC61131. Как я понял - Рефлекс это полный аналог PDU-SFC-ST. Т.е. что нового даст мне Рефлекс, кроме русских букв в идентификаторах и возможности хранить код в CVS?
4. Как я могу "прикрутить" Рефлекс к своему контроллеру (система исполнения, компилятор, ...)

(можно ссылками, но лучше - коротенько здесь)

Рефлекс - это развитие проекта СПАРМ (средство программирования алгоритмов работы
микроконтроллеров, авторы Зюбин В.Е., Карлсон Н.Н. 1988-1990 гг). Год создания настоящей
версии языка Рефлекс - 1998 (Зюбин В.Е. с участием Петухова А.Д., Данчина Д.Ю.). Год ее реализации
(создание транлятора) - 2002 год.

В основу языка Рефлекс легли идеи, почерпнутые из языков ЯРУС, Си, QuickStep, СПАРМ. Да, до СПАРМ был проходной вариант ЯРУС-П (ЯРУС на Паскале, 1985-86), не оконченный.

Так что генеалогия примерно такая:

(ЯРУС+Паскаль) -> ЯРУС-П (1986)
(ЯРУС-П+ЯРУС+Си) -> СПАРМ (1990)
СПАРМ + QuickStep -> Рефлекс (1998)

Разумеется, что оказывали влияние на Рефлекс и другие языки, те же языки МЭК 61131-3.
История использования:

- 1989-1992 - применялся при автоматизации электроавтоматики станков ЧПУ (СПАРМ,
адаптация на х86 + VME),
- 1994-97 - применялся для автоматизации установок выращивания монокремния методом
Чохральского 221УА100 (СПАРМ, адаптация на мультипроцессорной системе Intel 196 + Multibus)
- 2002-2005 - автоматизация установок выращивания монокремния методом Чохральского 221УМК090
(Рефлекс, адаптация MicroPC+UNIO)




Существует описание языка, в каком-то виде.
http://reflex-language.narod.ru/doc/index.html

Ну, а вообще планируется этот раздел расширять описанием трансляторов, библиотек для разных
платформ, проектов.



Ну в общем-то так, функционально язык покрывает SFC+ST. Ну и русскоязычность его один из
основных плюсов (впрочем, и англоязычность не исключается).

На мой взгляд основные преимущества языка Рефлекс (как языка):
1. Си-подобность = легкость изучения для Си-программистов, минимизация смешаноязыкового
программирования
2. Более удобные и надежные средства для управления потоками (SFC он ближе к сетям Петри со
всеми заморочками вокруг фишек, проблемой конвергенции потока управления и т.д.)
3. Однородность представления (чисто текстовый вид и все плюсы текстового представления:
потенциально высокая переносимость, модифицируемость текста и т.д.)

Ну, а плюсы текущей реализации языка (транслятора языка) таковы:
1. Полный контроль пользователя над исходными текстами, расширяемость,
2. Повышенная переносимость программ (адаптацию языка на платформе может делать пользователь),
3. Минимальные требования к целевой платформе... (шесть байтов на процесс, образы регистров УСО(~N*3), переменные, стек глубиной в два call-а без параметров)

Разумеется, при этом не исключается возможность и появление других вариантов реализации языка,
например, под интерпретационной моделью исполнения, с полновесными IDE и т.д.



Системы исполнения не требуется, на выходе получаются StandAlone приложения.
Разумеется, что не исключено исполнение под операционной системой.

Транслятор языка - по запросу, выходные файлы - на языке Си, со всеми вытекающими...
библиотеки открыты, системозависимых функций - от пяти до пятнадцати (зависит от случая).
В самом простом случае адаптация сводится к тому, чтобы:
а) организовать вызов функции Control() с заданной частотой,
б) написать функцию считывания байта/слова из модуля УСО,
в) написать функцию записи байта/слова в модуль УСО.

1. Извините, но какой контроль пользователя и над какими исходными текстами понимается?
2. Что понимается под расширяемостью языка?.

В моем понимании, язык расширяемый если его синтаксис и семантика могут изменятся
пользователем в сторону специализации.
Поправьте, если я не прав.

P.S. Что вы думаете о принципах предложенных в языке ДССП. ( http://forth.org.ru/~dssp )
( долгое время развиваемом в МГУ)

Сообщение отредактировал Kopa - May 11 2006, 12:28

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

Ну, а синтаксис языка Рефлекс при этом, разумеется, сохраняется.



Если честно, то я не понял, что это за язык и в чем его проблемная ориентированность. В вопросах-ответах этого, к сожалению, нет. А вот что меня озадачило (см. FAQ), так это то, что первая версия ДССП на два порядка более производительная, чем пятая... впрочем, может, для ДССП это не главное.
В общем, принципов ДССП я не понял, поэтому, к сожалению, прокомментировать их не могу.

Сообщение отредактировал Владимир Е. Зюбин - May 11 2006, 14:14

А почему нельзя сюда попасть с главной страницы?

За информацию - спасибо! пойду читать ...

Один из принципов - минимальный разрыв между системой команд языка и процессором
В идеале одна команда ЯВУ должна транслироваться в одну команду процессора.

Производительность версии, думаю, упала при усложнении внутренней организации рантайм
структуры языка ( может ООП навесили или что, то в этом роде )

Меня, в языке интересует наличие метапрограммирования, что из знакомства с Вашим языком
не видно.

Из плюсов Рефлекса - Язык покрывает часть возможностей предоставляемых операционной системой.
В этом плане, хотелось бы иметь возможность сопряжения языка с любой осью для МК.

Не совсем понятно, что Вы называете метапрограммированием. Как я понимаю - это создание средствами языка модификаций языка (а ля Лисп). В Рефлексе этого нет. Тут другая идея. Пользователь не язык конструирует, а описывает алгоритмы работы некой системы управления на языке очень похожем на Си. Это почти Си, но Си, расширенный понятием процесс. Вообще говоря, Рефлекс - это Си с процессами. Некая ортагональ к Си++ (который называли "Си с классами").

В Рефлексе (как языке) программа строится как иерархия процессов (логически параллельных потоков управления). И на основе такого подхода можно сконструировать произвольный процесс. Это основная идея языка Рефлекс, ну и его ориентация - это задачи автоматизации.

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

Но в принципе реализация может быть другая. Разработчик контроллера может "заточить" Рефлекс под свою платформу (создать полноценную IDE, реализовать компилятор Рефлекса, или там байт-код, или интерпретатор, и т.д.). Это будет альтернативная реализация языка Рефлекс.

[quote name='Владимир Е. Зюбин' date='May 12 2006, 07:09' post='112402']
[quote name='Kopa' post='112396' date='May 12 2006, 08:46']
Меня, в языке интересует наличие метапрограммирования, что из знакомства с Вашим языком
не видно.

Из плюсов Рефлекса - Язык покрывает часть возможностей предоставляемых операционной системой.
В этом плане, хотелось бы иметь возможность сопряжения языка с любой осью для МК.
[/quote]

Не совсем понятно, что Вы называете метапрограммированием. Как я понимаю - это создание средствами языка модификаций языка (а ля Лисп). В Рефлексе этого нет. Тут другая идея. Пользователь не язык конструирует, а описывает алгоритмы работы некой системы управления на языке очень похожем на Си. Это почти Си, но Си, расширенный понятием процесс. Вообще говоря, Рефлекс - это Си с процессами. Некая ортагональ к Си++ (который называли "Си с классами").

[/quote]
или (а ля Лисп) или что-то ( а ля Форт).
А решать задачу на низкоуровневых средствах, не имея возможности работать в терминах
предметной области мне не хочется. В этом случае сложность алгоритма при переходе
от одного уровня к другому линейна ( не упрощается). Работая с большим чужим С проектом
сложно, зачастую, отделять уровни абстракции.

[quote

Но в принципе реализация может быть другая. Разработчик контроллера может "заточить" Рефлекс под свою платформу (создать полноценную IDE, реализовать компилятор Рефлекса, или там байт-код, или интерпретатор, и т.д.). Это будет альтернативная реализация языка Рефлекс.
[/quote]

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

Сообщение отредактировал Kopa - May 12 2006, 04:51

Вообще работать с чужими большими проектами сложно. Тут уж ничего не поделаешь. Нужна документация. Дополнительный уровень абстракции. Мы используем блок-схемы. Чтобы охватить проект с высоту птичьего полета. Ну и, зачастую, сами же ими и пользуемся.

Что же касается Рефлекса, то это очень высокоуровневый язык (удобный для использования человеком). Основной довод - при общении с заказчиком мы пользуемся исключительно его терминологией. Да и вся программа терминологически сооветствует автоматизируемому объекту.
И диалог с заказчиом конструктивный и продуктивность работы высокая.



Тут надо поставить точки над i. Рефлекс не предназначен для "реализации операциональных возможностей среды". Он не для этого разрабатывался. Цель его создания - комфортное описание алгоритмов управления промышленными объектами: станками, конвейерами, роботами, и всяким прочим технологическим оборудованием, типа: насосы, клапаны, двигатели, источники питания и т.д. и т.п.

При РЕАЛИЗАЦИИ языка (а реализаций может быть много) нами в качестве выходного формата был выбран язык Си. Основная причина такого решения - простота реализации:
Не нужно писать кодогенератор для целевой платформы. При этом гарантируется хорошая оптимизация по производительности, заведомо более высокая, чем через псевдоассемблер. Ну и по мелочам: удобство настройки на платформу, отсутствие дополнительных ран-тайм ядер, прозрачность.

Опять же повторюсь, возможны любые другие подходы при РЕАЛИЗАЦИИ языка, в частности, через байт-код или псевдоассемблер, но, к сожалению, у нас такой реализации нет. А идея интересная, типа ISaGRAF-подхода, правда, могут возникнуть проблемы с использованием на низкобюджетных контроллерах.

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

для существующей и доступной реализации
схема создания программ на языке Рефлекс такая:


Т.е. в наличие есть только компилятор, генерирующий Си-код.
Описания его, к сожалению, нет. Только небольшой help по запуску без параметров.
Эдакий спартанский вариант. Как вариант (чисто теоретический, нужна проработка) можно встроить транслятор Рефлекс в препроцессор Си-транслятора целевой машины, тогда схема упрощается. (Для некоторых Си-трансляторов такая штука просто делается).

Насчет компилятора, генерирующего байт-код вопрос интересный, но, увы. :'(
Возможно, через некоторое время появится интерпретатор языка Рефлекс. Есть небольшая группа, которая исследует возможность адаптации Рефлекса на LinuxPLC.

Сообщение отредактировал Владимир Е. Зюбин - May 12 2006, 15:18

Не умоляя достоинств С программирования, в очередной раз попалась ссылка
на применение Форта для решения задач автоматизации http://www.forth.org.ru/~st/
( j,jheljdfybz на хлебокомбинате.)

Хотелось бы услышать мнение по этому поводу почему так происходит.

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

В документации сказано:

1. "2.5.4 Адрес регистра в модуле IO может быть в диапазоне от 0 до 2;"
Какой в этом смысл, если
"2.5.5 Адрес модуля IO может быть в диапазоне от 0 до 0xFFFFF"

2. "2.6.8 Возможны процессы, использующие пересекающиеся множества входных и выходных переменных."
Кто последним установит выход, т.е. как определяется последовательность выпонения процессов?

3. "2.7 - в состояниях нет возможности организации циклов и переходов"
Не совсем ясен смысл - 'for' и 'while' отсутствуют, или нет перехода сам в себя?

4. "2.11.5 Описание программы начинается с резервированного слова "Прогр""
А как задается точка входа (типа 'main')? Или нет главного процесса - все процессы стартуют вместе?

5. 'ТАКТ' един для всех процессов или каждому процессу можно назначить свой 'ТАКТ'?