Возражений нет. Для более подробного ознакомления можно посетить
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 )
( долгое время развиваемом в МГУ)

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

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



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

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

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

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

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

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

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

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

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

В текущей версии транслятора (не языка, а транслятора языка) выходные файлы после трансляции - это файлы на Си. Такой подход обеспечивает переносимость программ на произвольную платформу.
Реализация программ, написанных на языке Рефлекс (выходные файлы на Си), ориентирована на 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 файла. Или мнемоники псевдоассемблера

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

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



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

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

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

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

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


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

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

Не умоляя достоинств С программирования, в очередной раз попалась ссылка
на применение Форта для решения задач автоматизации 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. 'ТАКТ' един для всех процессов или каждому процессу можно назначить свой 'ТАКТ'?

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

Для меня и не только, при кажущемся неудобстве и простоте синтаксиса, сравнимом
с ассемблером, Форт остается мощнейшим из созданных языков программирования
со своей парадигмой разработки программ.
Познакомится с языком можно по изданной литературе ( начав с рускоязычного ресурса 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://raps-technol.narod.ru/

АВТОМАТИЗАЦИЯ ПО-РУССКИ
Распределенная Аппаратно-Программная Среда ("РАПС") - новый подход к построению АСУ промышленного и бытового назначения.

Сразу должен сказать, спасибо Вам, Andrew2000, за эти вопросы. Глубоко копнули.
А на хорошие вопросы всегда приятно отвечать.


Большое спасибо за замечание! Это проблема документа, который писался в пакете и во взаимоувязке
с конкретной системой и конкретной библиотекой. На самом деле, это описывается интерпретация параметров для конкретной платформы (MicroPC+УСО UNIO): УСО типа UNIO просто сидят на XT магистрали и имеют три регистра, что относится к платформе, а не к транслятору языку.
Транслятор языка проверяет только то, что это число (числовая константа). Ну и подставляет эти числа как параметры при вызове функции считывания (записи) значений в IO-модули.

Разумеется, что функции считывания (записи), которые привязаны к платформе и описываемые отдельно при портировании, могут интерпретировать эти числа как угодно, например, как некий адрес в ОЗУ.

Спасибо за замечание. Это моя вина, надо было внимательно просмотреть описание, перед публикацией. Файл подкорректировал и обновил на сервере.

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

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

Использовать эту информацию, строго говоря, некорректно. Мы, по крайней мере, не используем.

Да. Конструкции типа for и while в языке отсутствуют.
Вызвано это идеологическими причинами: в языке нет "естественной"
возможности глобально "завалить" программу.

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

Главный процесс - описанный первым. С него и начинается раскрутка алгоритма.
По включению питания (по запуску). Все процессы, кроме описанного первым, находятся в пассивном состоянии.

Типовая схема примерно такая: первый процесс инициализирует структуры, протоколы, драйверы, "взбадривает" железо, а затем уже переходит к собственно логике: начинает порождать параллельные потоки (запускать нужные процессы). Ну, или чего там ему сказано делать...

В текущем варианте языка - ТАКТ один для всех. Проработан вариант изменения синтаксиса в этом направлении, но по реальной надобности пока не ощущается.

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

Если интересно, то этот вопрос обсуждается тут:
Зюбин В.Е., Петухов А.Д. Распределение вычислительных ресурсов с многопоточной реализацией гиперавтомата // Труды III Международной конференции <Идентификация систем и задачи управления> SICPRO '04. Москва 28-30 января 2004 г. С. 446-463 (pdf 366Kb).

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

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

[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. Переопределив уровень управления рантайм средой на свои процедуры.
И создав необходимый уровень реализации, при этом и изменив синтаксис и семантику
наполнения. При этом программа может выглядеть, как на языке Рефлекс ( например).
В процессе компиляции будут создаваться требуемые структуры для работы программы.

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

А ISaGRAF и CoDeSys, например, используют. Как раз "некорректно" будет, если я (пользователь) не знаю, что там внутри творится.
Запишем в минусы текущей реализации.


Ну, на двух состояниях я ее также "завалю".

И еще забыл спросить - что выполняется за такт?
Т.е. с чего такт начинается и чем заканчивается - где "водораздел" - операторы перехода в след. состояние выполняются в этом такте или в начале нового?

Спасибо за ответы

Приведенную задачу действительно можно можно решать и на ассемблере и в машинных кодах, и на Си, и уверен, что на Форте.

Проблемы тут видятся такие:
1. Дополнительный объем работы (нужно разработать стратегию управления)
2. Неустойчивость решения (разработанная стратегия находится вне языка, а, значит, нужна некая
дисциплина разработки, культура, квалификация)
3. Возможны проблемы с надежностью (пониженная надежность), т.к. разработанная стратегия
наверняка будет иметь и свою семантику, которую невозможно будет проконтролировать на уровне
базового транслятора. Не знаю, насколько это понятно... Попробую пример привести.

Не знаю, насколько расширяем в этом смысле ФОРТ.

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

====

Что касается уровня "рантайма" Рефлекса:
тут разговор не о языке, а только об одной из реализаций языка Рефлекс (по аналогии с Си, и его разными вариантами реализации: от Борланд, от MS, от Watcom... реализаций несколько десятков, подходов - тьма, есть даже интерпретатор Си).

Так вот. В доступной на сегодняшний день реализации, действительно, настройка на конкретную платформу осуществляется отдельно, возможно, производителем контроллера или даже пользователем.
Нужно обеспечить 1) тактируемый вызов функции-цикла обработки (связано с прерываниями от таймера, службой времени), 2) запись/считывание портов входа/выхода (связано с системной магистралью, драйверами IO).

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

Это ни в коем случае не исключает появление других подходов на базе языка Рефлекс.

Разрабатывать стратегию управления придется, если не брать стандартные решения.
Решение будет находится в рамках Форт языка.
Автоматы на Форт языке пишутся легче, чем с использованием других языков ( Примеры тоже есть)
В плане понимания возможносей языка полезно прочитать "Thing Forth" Броуди
( неизданная в печатном виде книга, полезна всем кто занимается разработкой программ)
есть русский перевод Дмитриева.

Разработаны включения синтаксиса Си языка в Форт систему. ( в виде приинклюдивания
файла с расширением ).


Недостатки Си языка в приложении к контроллерам мне хорошо видны, т.к. приходится
его использовать. Рефлекс в этом плане закрывает некоторый пробел.
Не думали вместо Си использовать Javу?

Ну, наверное, все же не ISaGRAF использует, а пользователи ISaGRAF-а. И тут видится нехороший момент: в стандарте МЭК-61131-3, насколько я знаю, это не прописано. Также и документации на ISaGRAF я этих вещей не припомню. Хотя, действительно, порядок определен. Но использование этой информации - это область трюков, усложняющих программу.

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

В связи с этим повторюсь:
При программировании на Рефлексе тоже можно использовать информацию о реализации. Но приводит к усложнению сопровождения программы (снижение читаемости, понимаемости, модифицируемости и т.д.) и снижение ее надежности. Поэтому конкретно мы, сами не используем такие трюки, ну и другим не советуем. Но информация о реализации доступна: можно, что уровень Си-посмотреть, что так могу сказать: последовательность исполнения определена порядком описания.



Ну, вроде как, не получается. "Завалить" программу локальными операциями языка Рефлекс невозможно (вроде б). Можно либо выходя в Си, либо глобальными операциями типа
остановить все процессы, а потом остановить и себя.



За такт выполняется стандартный набор действий "ввод-обработка-вывод".
Насчет операторов перехода - вопрос глубокий и серьезный. Прям в точку.
Если честно, то ситуация у нас получилась такая: алгоритм обработки может настроить пользователь, через библиотеки. Такая вот петрушка.

Ну а вообще. Исторически, в одной из первых реализаций для платформы х86+VME, была реализован
алгоритм такой: операторы смены состояния вступали в действие только по окончанию такта.
А потом поработали с этим, поработали, да и отказались. Смысла нуль. Так что в текущих системных библиотеках оператор смены состояния вступает в действие сразу. Как встретился, так и отработал.

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

Ну а в общем, дело вкуса.

Было бы интересно взглянуть на внятные примеры или статью на эту тему.



Мне все-таки думается, что Си-язык используют не из-за его недостатков, а из-за его достоинств:
а) распространен, известен
б) первый платформонезависимый язык, что появляется на новой платформе
в) эффективен

Наверное вместо Си можно использовать и Яву, минусы: Ява менее распространена и более ресурсоемка. Но в принципе, почему бы и нет. Если кому-то это нужно, можно даже и посодействовать.

[quote name='Владимир Е. Зюбин' date='May 17 2006, 14:55' post='113965']
[quote name='Kopa' post='113834' date='May 17 2006, 11:34']
[quote name='Владимир Е. Зюбин' post='113822' date='May 17 2006, 07:20']

Приведенную задачу действительно можно можно решать и на ассемблере и в машинных кодах, и на Си, и уверен, что на Форте.


[/quote]

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

[/quote]

Наугад загуглил Форт Автоматы состояний и вот первая из ссылок на странице:

http://is.ifmo.ru/books/switch/2

в Приложение 9. Использование языка "Форт" при реализации автоматов

или вот из обсуждения проги для генерации С кода для автомата состояний (http://fsme.sf.net )
...
Самая изящная реализация КА, которую я видел -- непосредственное исполнение Форт-системой таблицы состояний автомата. Описано в Computers in Physics где-то в начале 90-ых, ксерокопию статьи можно взять в ftp://gleb.iao.ru/archive/archive/Info/Ar...orth(CiPh).djvu

Дальше не стал приводить...
Если пошире поискать, то найдется еще.

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



Я не сомневаюсь, что на форте реализация автомата может быть выполнена самым изящным образом, хотя статьи скачать не смог.

Но вопрос не в реализации, как мне это видится, а в представлении для программиста и удобстве программирования. Реализация тут все-таки вторична.

Не вступая в полемику можно сказать следующее:
1. Чуждая семантика для тех, кто привык к одной форме выражения программы.
Гибкость синтаксиса языка напрямую зависит от фиксированности структуры языка.
Если структура минимально фиксированна, то выразительная гибкость возрастает.
Мне, например, неудобно решать задачу, когда приходится искать адекватные
возможности в языке, а не простым действием создав их. Соответственно диапазон
возможных решений сокращается из-за ограничений языка.

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

Действительно со сложившимися стереотипами приходится считаться, но если
при развитии язык не вбирает лучшее из других языков, то зачем мне такой язык?!:)

P.S. Некоторые прописные истины не грех лишний раз повторить.

Про семантику я заговорил, имея ввиду возможность создания своей семантики.
например программируя на ассемблере, невозможно ввести концепты типа "структура", "выражение".
Программируя на Си невозможно создать концепт "класс", "объект". Их можно только реализовать, ручками, рутинно, с кучей ошибок. Также средствами Си++ невозможно создать концепт "процесс".
Можно только реализовать. Я об этом говорю.

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

Есть же стандартизация... стандартные методы, парадигмы, стратегии, подходы... разумеется эти вещи ограничивают гибкость, сужают круг решаемых задач, но при этом снижается и сложность создания/сопровождения, повышается надежность. Это и есть суть проблемно-ориентированных языков.
Ассемблер - это абсолютная гибкость и эффективность, Си - это потеря эффективности, потеря связи с платформой, но и платформонезависимость, переносимость, Си++ - ориентация на WIMP-интерфейсы, Фортран - инженерные расчеты, Паскаль - обучение структурному программированию... Ada - надежность комплексных проектов, и т.д. и т.п.



Тестирование - это действительно один из подходов, не самый плохой. Но и не без недостатков.
ЧТо плохого, если сам язык содействует созданию надежных программ? По моему, так это здорово.



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

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

Немного информации.

http://www.chipinfo.ru/literature/chipnews/200303/7.html

В данной статье про ДССП высказано следующее мнение:

Кроме того, наше программное обеспечение построено на западных операционных системах (ОС) и языках программирования, не защищено от взлома, вскрытия, то есть не соблюдается элементарная информационная безопасность. Выход из тупика - в использовании отечественных технологий. Примером такой технологии является ДССП и язык РАЯ (МГУ, Брусенцов Н.П.). РАЯ — единственный в мире истинно структурированный язык: Паскаль позволяет писать структурированные программы, а РАЯ - не разрешает писать неструктурированные программы. Разработка ПО в ДССП ведётся снизу-вверх, что обеспечивает надёжную верификацию программного продукта. Сегодня переход на отечественные программные технологии нереален, но когда-то нужно опомниться

Дает почву для размышлений и следующий диспут.

http://www.arbinada.com/_resources/misc/sedov_dispute.html

P.S. Что в разработке программ не так

Все, т.к. многое в статьях правильно представлено.
Но, к сожалению, и рецептов четких нет.
Зачем подмножество Паскаля, если есть Паскаль? Хочешь программируй и так и этак. На "истинно структурном" - только структурно. Ну и будете Вы самый чистый, но единственный в мире программист на специализированном (структурном) языке. "Шаг влево, шаг вправо - попытка к бегству" - так?
Зачем Рефлекс, если уже есть Си? На Си программируют даже школьники.
"Чистота" должна быть не в языке, а в мыслях и в выражении их. А просто, доступно, ясно и надежно можно "мыслить" и на Си. Думать только надо! Прежде всего об этом речь в указанных статьях...

Вступлюсь за Рефлекс... :-)

Рефлекс - это не подмножество Си, а его диалектическое расширение. Ровно как и Си++, только немного в другую сторону. Си++ расширяет Си до Си с классами, а Рефлекс расширяет Си до Си с процессами.

Насчет же структурного программирования и всяких GOTO, считаю, что любая абсолютизация вредна. И желание писать полностью в структурном стиле, и в объектном... Исключения из правил могут позволить упростить описание алгоритма. Это надо использовать с умом.

Подобных "расширений" Си- множество. При этом и язык новый изучать не нужно и возможность работы с процессами есть. К чему еще одно "расширение"? Старых мало?

Расширений Си действительно много:
Си++, Java, Java script, Си-шарп, php, в конце-концов... есть и менее распространенные, знаю, например, верифицирующие расширения Си...
Но диалект Си для класса задач управления один - это язык Рефлекс. ;-)

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

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

Если вы занимаетесь базами данных, или графикой, или WIMP-интерфейсами, или распознаванием образов, пишете трансляторы, занимаетесь созданием Веб-сайтов, работаете системным администратором, то изучать Рефлекс нет необходимости. Если Вы работатете в области пром. автоматизации, но алгоримты простенькие - то же... вас может вполне устроить один из языков МЭК 61131-3... можно и их поизучать (правда, их пять и они совсем непохожи на Си ;-).

"К чему еще одно "расширение"?" - да к тому, что Рефлекс преподносится публике не верно. Отсюда и вопросы такие. Никакое это не расширение С, а совсем другой язык, просто использующий синтаксис подобный С. Ноги растут не оттуда.
Владимир Е. Зюбин в начале ветки писал:
"В основу языка Рефлекс легли идеи, почерпнутые из языков ЯРУС, Си, QuickStep, СПАРМ. Да, до СПАРМ был проходной вариант ЯРУС-П (ЯРУС на Паскале, 1985-86), не оконченный."
И рассматривать Рефлекс надо как развитие этой ветки, и сравнивать его с языками IEC61131, а не С.


Ну, это Вы замахнулись. Есть еще, например, CLL - "Язык программирования алгоритмов логического управления". Это я откопал устаревшее описание, последний вариант использует язык С (асм, тоже никто не отменял).

Кстати, хотелось бы услышать Ваше мнение по CLL (в стиле "найдите 10 отличий")

Думается, все же не стоит ограничивать рассмотрение Рефлекса только сравнительным анализом с МЭК 61131-3, ЯРУС, ЯЛУС, QuickStep, СПАРМ и т.д. При рассмотрении Рефлекса как расширения Си, ортагонального Си++, весьма интересно. Приводит к весьма забавным мыслям и идеям относительно объектно-ориентированного программирования и его составляющих (наследование, инкапсуляция, полиморфизм).
Истина, она же в сравнении познается, не правда ль? ;-) Кстати, на эту тему, в конце прошлого года были публикации (по гиперавтомату), да и в этом уже появились, ну и, надеюсь, еще появятся.



Спасибо за ссылку. Интересно узнать были ли публикации по ЯЛУС, где и когда. И вообще, каким образом Вы на этот язык вышли. Очень интересно.

Что касается 10-ти отличий:
Первое впечатление очень хорошее, радует русскоязычный синтаксис, видно, что проделана очень большая и полезная работа, чувствуется влияние идей ЯРУСа (не только в названии).
Если заменить понятие "программа" на "процесс", а "ситуацию" на "состояние", то ЯЛУС-CLL (текстовая форма ЯЛУС) становится очень похож на СПАРМ.

Конкретнее ремарки по тексту (отличия CLL и Рефлекс, кроме уже упомянутых терминологических отличий):
1. стр. 4. В CLL есть таймерные переменные в Рефлексе их нет (работа со временными интервалами реализуется через оператор ТАЙМАУТ). В терминах переменных - таймерные переменные в Рефлексе описываются неявно и их очень много.

2. стр. 4 В CLL программы могут быть установлены извне в произвольную ситуацию (пустую), включены и выключены, в Рефлексе "пустые" ситуации жестко специфицированы, это два пассивных состояния: состояние нормального останова (СТОП) и состояние останова по ошибке (ОШИБКА), и, соотвественно, извне процесс может быть либо запущен (переведен в начальное состояние оператором СТАРТ), либо остановлен - т.е. переведен либо в состояние СТОП, либо ОШИБКА (операторы СТОП/ОШИБКА). Если кратко - в Рефлексе реализован некий аналог структурного программирования.

3. стр. 5. Похоже, что в CLL предполагается, что параллелизм обеспечивается на уровне ОС, или некоего ядра-супервизора - разделение по времени (отсюда рассуждения о семафорах и т.д., стр.23...), Рефлекс не исключает такой реализации, однако больше ориентирован на кооперативную многопоточность в стиле round-robin (нет проблем с конфликтами доступа).

4. стр. 6. В CLL автоматическая привязка к модулям УСО специфицируется одним числом, в Рефлексе - двумя (исторически это база+смещение). Не принципиально, но может привести к проблемам. В CLL - для привязки переменной следует указывать бит в порту, в Рефлексе - автоматически, по мере перечисления. В некоторых случаях, способ CLL удобнее.

5. В CLL - выход на ассемблер, в Рефлексе выход на Си (ассемблер, только если он предусмотрен целевым транслятором)

6. стр. 6. Про блок-схему я не понял. Сначала говорится, что графика - это одна из версий модели ЯЛУС, при чем тут CLL?

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

8. стр. 7. В CLL встречаются следы Паскаля: оператор "конец". В Рефлексе - Си-шный стиль - тела процессов и сотсояний обрамляются фигурными скобками - {}.

9. в CLL имеются особые операторы (вкл, откл, считать) для работы с переменными, в Рефлексе сохранен "сишный" стиль - операторы =, !=, == и т.д. Небольшое исключение - операторы работы с процессами (СТАРТ/СТОП/ОШИБКА).

10. Похоже, что в CLL отсутствует конструкции типа ЕСЛИ-ТО-ИНАЧЕ, без ИНАЧЕ - тяжело. В СПАРМЕ его не было. Мучались. Кроме этого в Рефлексе и оператор ВЫБОР есть (аналог switch). ну и вообще, в Рефлексе - сишный стиль ЕСЛИ-ИНАЧЕ... скобки, произвольная вложенность и т.д.

11. стр. 8 В CLL переменные глобальные, "видимы из всех программ"... а в Рефлексе - переменные имеют степень доступа и видимости. Можно использовать переменные с одними и теми же именами.

12. стр. 9. В CLL начальное состояние программ специфицируется "вручную" (операторы вкл, выкл), в Рефлексе состояние процессов по запуску специфицировано жестко - активен только начальный процесс, все остальные - пассивны.

13. стр.9-10. В CLL - есть механизм меток, в чем-то альтернативный ситуациям. В Рефлексе этого механизма нет, более того, как уже говорилось, воздействия извне ограничены тремя командами (СТАРТ/СТОП/ОШИБКА).

14. стр. 12, стр. 14 упоминается о кодах времени, спецификации интервалов времени n.m (сек.мс), и длительности цикла. спецификация интервалов - это достаточно удобная вещь, в Рефлексе ее нет (только планируется), а вот о спецификации длительности цикла я ничего не нашел. В Рефлексе - тактируемая цикличность исполнения описывается прямо - оператором спецификации такта - ТАКТ.

15. Не встретилось в описании CLL (может пропустил) упоминание об арифметических операциях типа умножение, деление. По-видимому, ориентация языка CLL в основном на логическое управление, Рефлекс не ограничивает использование Си-операторов, и позволяет описывать те же ПИД-регуляторы, делать другие математические расчеты.

16. Вообще по тексту примеров несколько озадачило присутствие идентификаторов типа _001, _086 (стр.17), и малоинформативных имен программ/ситуаций. Но это скорее по стилистике.

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

Я же написал, что это устаревшее описание, современная реализация имеет выход на С.


Можно вставлять любые инструкции С и асм - типа __asm{ .... }


Задается в файле проекта при компоновке.


стр. 6 - "В языке CLL отсутствуют операции с вещественными числами, а также операции с целыми числами, время выполнения которых зависит от значения операндов (например, умножения и деления)." Но, если время выполнения не страшно - можно делать С-шные вставки.


Ну, это просто пример. Так технолог написал - у него так провода на схеме называются ...

В проекте СПАРМ был прокол в идеалогической части, глупая идея отразить смешанный (Мили/Мура) автомат в его классическом виде. В результате - оператор ИНАЧЕ(else) отсутствовал как класс. В сложных проектах при использовании СПАРМ нам постоянно приходилось пользоваться Си-шными вставками. Это ужасно напрягало (хотя была целочисленная арифметика). А в CLL получается, например, что описываются чисто логические алгоритмы, и использовать ПИД-регулятор уже не удается.

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

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

Вопрос такой: где Вы публиковали результаты по CLL? Язык очень интересный, его невозможно игнорировать, и хотелось бы иметь ссылку на статьи по языку. Ну и по ЯЛУС.

Так в документе так и сказано - стр. 6: "Поскольку язык прежде всего, предназначен для программирования алгоритмов логического типа с _фиксированной длительностью цикла_".
В каждой отрасли свои традиции, т.к. тут ПИД-регулятор никому не нужен, про него никто и не думал. CLL создавался для конкретных применений - стр. 1: "СLL (Control Logic Language) был разработан для стендовых систем управления испытаниями ракетно-космической техники".


В CLL такая же фигня - С-шными вставками не пользуются, когда применяют его по-назначению
Тогда получается - одна команда CLL - одна команда процессора (выход на asm, например, для Infineon SAB).


Складывать и вычитать, как раз можно, делить и умножать нельзя.


Во-первых, публиковал не я, т.к. не автор. Во-вторых, наверное, не публиковали. Все, что есть - выложил в этой ветке.

Попалась интересная статья по генерации нативного
кода из байтового представления.
Адрес ссылки для ознакомления
http://www.softcraft.ru/translat/etc/rubst/rubberstack.pdf

P.S. к вопросу способа промежуточного представления программы.

Понятно. А что значит, "с фиксированной длительностью цикла" и почему это несовместимо с операциям умножения?



Вот это-то и вызывает вопросы... Почему?



Очень жаль, очень жаль... результаты действительно инетересные... непонятно, каким образом авторы планируют защищать свои приоритеты? Вернее, непонятно, почему они их не защищают стандартным способом - через публикации? Это что, ноу-хау, или ограничения со стороны первого отдела?
Вроде б под запрет не попадает. Блин! - а других слов нет. Придет какой-нибудь CLL от Сименс, вот и будут потом волосы рвать.

"Публикуйся, а то проиграешь!"
"Работу форсируй, результаты - фиксируй!"

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

Та версия, описание которой я выложил ориентирована на проц. Infineon SAB. У него операции сложения и вычитания - один такт, а умножать и делить он может тока за несколько тактов.
Получается - одна команда CLL - одна машинная команда. Т.о. в среде разработки можно посчитать время выполнения куска кода по командам CLL.


От кого защищаться-то? Плохо помню историю, но, кажется язык создавался в 198х для испытаний двигателей БУРАН-а. И по сей день применяется для испытаний ракетных двигателей. Есть несколько дисеров.

не очень понятно... время операции - такт, а время выборки из ОЗУ/ПЗУ? и почему нельзя посчитать количество тактов на умножение/деление? они же тоже известны.

Но самое главное, непонятно, зачем эти такты считать вообще. Там что, тамера нет?



Защищаться нужно не от кого, а что - приоритеты, авторство. Ну и для научного сообщества польза - не нужно изобретать вилосипед, а можно использовать наработки для продвижения вперед...
вот бы все теорему Пифагора доказывать стали... или теорему Котельникова... где б мы все были?

Информационное сообщение:

Среди статей по языку Рефлекс появилась небольшая статья по математической
модели гиперавтомата, которая лежит в основе языка Рефлекс.
Небольшая критика модели конечного автомата, всякие слова
про процессы, событийный полиморфизм, и т.п.

http://reflex-language.narod.ru/articles/articles.htm

Также по материалам этой ветки форума на сайте был введен раздел с часто-задаваемыми вопросами.
Спасибо Andrew2000, locas, Kopa и всем остальным за вопросы и ценные ремарки.

Вот встретилась информация для размышления.
Автор предлагает некоторый пересмотр технологии создания ПО и вводит парадигму
получившую название языково-ориентированное программирование.

http://www.rsdn.ru/article/philosophy/LOP.xml

P.S. Форт язык всегда был ориентирован на данный подход.
Жаль, что некоторые вещи переоткрываются только сейчас.
По принципу "Новое - это хорошо забытое старое"
Хотя про Форт этого не скажешь