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

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

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

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

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

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

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

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

Сделать, на Форте можно , как я понял необходим планировщик параллельных процессов.

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

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

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

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

Скажем есть т.н. switch-технология, которая базируется на известной реализации автомата на Си, когда состояния автомата кодируются числами (0, 1, 2, 3...), которые хранятся в выделенной ячейке памяти - глобальной переменной: z1 (для автомата №1), z2 (для автомата №2), и т.д. Так вот. Скажем, кодируемый автомат #4 имеет три состояния. И чтобы перевести этот автомат в третье состояние надо на Си просто написать

Код

z4 = 3;

куда казалось бы проще, да только транслятору Си никак не пояснить, что значение z4 не может быть больше трех. И с таким же успехом можно написать и

Код

z=125;

Можно придумывать всякие ухищрения, но все они будут далеки от оптимального решения - проверки на уровне семантики, автоматической и проводимой до этапа исполнения. Надо просто подсчитать число состояний в автомате №4 и контролирвоать. Но в Си нет такого понятия как "состояние". Это трагедия.

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

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

====

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

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

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

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

[Kopa]

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

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

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

====

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

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


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

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

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

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

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

====

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

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

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

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

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

[Kopa]

[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

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

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

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

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

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

Наугад загуглил Форт Автоматы состояний и вот первая из ссылок на странице:
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

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

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

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

[Kopa]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Kopa]

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

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

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

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

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

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

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

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

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

[locas]

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

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

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

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

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

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

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

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

[locas]

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

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

[Andrew2000]

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

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

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

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

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

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

Прикрепленные файлы

 CLL.zip ( 250.04 килобайт ) Кол-во скачиваний: 195

 

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

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

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

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

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

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

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

Что касается 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), и малоинформативных имен программ/ситуаций. Но это скорее по стилистике.

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

[Andrew2000]

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

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

10. Похоже, что в CLL отсутствует конструкции типа ЕСЛИ-ТО-ИНАЧЕ, без ИНАЧЕ - тяжело.

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

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

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

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

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

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

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

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

10. Похоже, что в CLL отсутствует конструкции типа ЕСЛИ-ТО-ИНАЧЕ, без ИНАЧЕ - тяжело.

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

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

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

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

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

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

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

[Andrew2000]

... А в CLL получается, например, что описываются чисто логические алгоритмы, и использовать ПИД-регулятор уже не удается.

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

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

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

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

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

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

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

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

... А в CLL получается, например, что описываются чисто логические алгоритмы, и использовать ПИД-регулятор уже не удается.

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

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

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

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

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

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

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

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

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

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

[Andrew2000]

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

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

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

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

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

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

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

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

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

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

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

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

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

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