Язык Рефлекс - диалект Си для программирования ПЛК, обсуждение, критика, вопросы Опции

[Владимир Е. Зюби...]

Есть предложение - может Владимир Зюбин создаст на форуме отдельную ветку для обсуждения Рефлекса? У меня есть желание задать вопросы по языку.

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

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

[Andrew2000]

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

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

[Владимир Е. Зюби...]

А вопросы такие:
1. История возникновения языка - год, автор, от кого произошел, ...

Рефлекс - это развитие проекта СПАРМ (средство программирования алгоритмов работы
микроконтроллеров, авторы Зюбин В.Е., Карлсон Н.Н. 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)

2. Users Manual на сам язык (по примеру на сайте можно понять, но тяжело :)

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

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

3. Кратко - 10 отличий от IEC61131. Как я понял - Рефлекс это полный аналог PDU-SFC-ST. Т.е. что нового даст мне Рефлекс, кроме русских букв в идентификаторах и возможности хранить код в CVS?

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

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

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

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

4. Как я могу "прикрутить" Рефлекс к своему контроллеру (система исполнения, компилятор, ...)
(можно ссылками, но лучше - коротенько здесь)

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

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

[Kopa]

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

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

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

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

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

[Владимир Е. Зюби...]

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

[Владимир Е. Зюби...]

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

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

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

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

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

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

[Kopa]

[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

[Владимир Е. Зюби...]

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

[Владимир Е. Зюби...]

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

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

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

[Kopa]

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

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

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

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

Для меня и не только, при кажущемся неудобстве и простоте синтаксиса, сравнимом
с ассемблером, Форт остается мощнейшим из созданных языков программирования
со своей парадигмой разработки программ.
Познакомится с языком можно по изданной литературе ( начав с рускоязычного ресурса forth.org.ru ).
C середины 90х годов в России литература по данному языку не издавалась.

В качестве коммерческого продукта в россии он все же используется, как встроенный в
средство автоматизации планировщика nncron ( nncron.ru) на PC . На нем также написан мультисервер
eserv ( eserv.ru). Частично, как скриптовый язык он один из реальных участников процессов
автоматизации производства.

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

Программа представляет цепочку взаимодействующих слов, без явной связи по параметрам.
Стандартным компонентом языка для передачи параметров является стек. Стек также
является вычислительным устройством языка. ( Например типичное сложение с участием
стека можно выразить так 5 4 + результат останется на стеке заменив числа 5 и 4 )
Введение скобочной записи не представляет сложности. Типов данных как таковых
в языке почти нет ( char , int , double int, float ). Типы данных никак не определяются.
Для Char и int при арифметических операциях выделяется одна ячейка стека ( в зависимости от разрядности системы) для double 2-e ячейки. Float заносится на свой стек данных.
Операции над числами одинарной или двойной длины отличаются добавочным признаком в слове.( т.е. в зависимости от требуемого действия выбирается соответствующее слово).
Слово никак не контролирует обрабатываемые параметры на стеке. Для безнакового сравнения есть свое слово. В языке отсутствуе механизм меток.

В двух словах примерно так, думаю основное для понимания представил.
Такое вот это чудо при первом рассмотрении. Находит как сторонников так и критиков.
Про стратегию управления не совсем понял.
Хочется адекватных возможностей в классических языках.

Фирма kaskod.ru в части своих изделий встраивает Форт в качестве стандартного
средства программирования. Есть процессоры и контроллеры с аппаратной поддержкой
стековой модели вычислений, есть смешанные. Много чего еще по данной тематике наработали.
Примеры тут приводить, пока, не имеет смысла. Многие специалисты даже и не знают
о существовании и возможностях данного языка. А часть может думать, что это сокращение
от Фортрана.

[Владимир Е. Зюби...]

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

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

<...>Про стратегию управления не совсем понял.

Ну вот например, есть классическая задача из области автоматического управления:
http://reflex-language.narod.ru/bottle/spec_bottle.htm . Для нее имеется целый ряд решений для разных языков. На сайте - решение для Рефлекса (грубо): выделяется пять процессов, запускатеся, так-то функционируют, приведен текст программы и описание. Известно как эта задача решается на всяких DECN-ах и т.п.
см. например, http://reflex.freebox.ru/pub/98glang.pdf.
Все по разному. А как это сделать на ФОРТе? Непонятно.

В этом и вопрос про стратегию.

[Kopa]

[quote name='Владимир Е. Зюбин' date='May 16 2006, 11:27' post='113503']

<...>Про стратегию управления не совсем понял.
[/quote]

Ну вот например, есть классическая задача из области автоматического управления:
http://reflex-language.narod.ru/bottle/spec_bottle.htm . Для нее имеется целый ряд решений для разных языков. На сайте - решение для Рефлекса (грубо): выделяется пять процессов, запускатеся, так-то функционируют, приведен текст программы и описание. Известно как эта задача решается на всяких DECN-ах и т.п.
см. например, http://reflex.freebox.ru/pub/98glang.pdf.
Все по разному. А как это сделать на ФОРТе? Непонятно.

В этом и вопрос про стратегию.
[/quote]
Сделать, на Форте можно , как я понял необходим планировщик параллельных процессов.

1. Также как пишутся ОС на Си с ассемблернными вставками.
2. Переопределив уровень управления рантайм средой на свои процедуры.
И создав необходимый уровень реализации, при этом и изменив синтаксис и семантику
наполнения. При этом программа может выглядеть, как на языке Рефлекс ( например).
В процессе компиляции будут создаваться требуемые структуры для работы программы.

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

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