Программирование ПЛК110 [М02] для задач реального времени

[Филоненко Владислав]

Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.

Регистры не переиспользуются и не должны.
Исключения т.н. макросы (сборки из блоков без внутренней памяти с однозначным потоком исполнения без циклов, например комплексный 4ANDNOT из 3-х AND и NOT).

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы. Результаты промежуточных вычислений (с т.з. процедурного подхода) не являются промежуточными.
По аналогии, если бы некая цифровая схема по мере прохождения сигнала по лог. элементам переставляла бы проводники (регистры) с входов лог. элемента на выходы. Для экономии меди в стране.
Пока у нас однозначный поток данных - так делать можно (теоретически).
Как только есть кольца, ячейки памяти, линии задержки и пр. - такой подход бы приводил к неопределённости поведения и часть линий пришлось бы сделать "запретными".

Например в Овен Лоджик блок расчёта таких "запретных" линий, где надо делать промежуточную ячейку памяти занимает немалую часть логики среды разработки и даже после годов отладки иногда бывают "особые ситуации".

На самом деле при байтовом I/O PRU уже имеет до 28*4 только регистровых переменых. А битовых в 8 раз больше. + куча ОЗУ.
Для логики RT управления дискретными I/O этого более чем достаточно.
А вот если всякие S-кривые в плавающей точке вычислять 1000000 раз в секунду - тут надо подход изменять, а не brute forсe-ом ломится.

[Владимир Ситников]

Концепция сверхжёсткого реального времени с 100% гарантией исполнения алгоритма не позволяет переиспользовать ресурсы

1) На самом деле, позволяет. Например, для умножения WORD'ов достаточно сделать 16 итераций цикла. На этих итерациях можно переиспользовать переменные. Никто не пострадает. Можно всегда крутить все 16 итераций и время выполнения вообще константным будет. А можно и выходить из цикла пораньше (если числа маленькие) -- тогда останется время на другие задачи.
2) Для большинства типичных случаев сверхжёсткий realtime и не нужен. Ну на кой нужен этот самый realtime, если мы ШД крутим?

Например в Овен Лоджик блок расчёта таких "запретных" линий, где надо делать промежуточную ячейку памяти занимает немалую часть логики среды разработки и даже после годов отладки иногда бывают "особые ситуации".

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

Вот ФБ для "линии задержки":
Снимок экрана 2016-10-04 в 20.29.51.png

Вот программа с его использованием. Надеюсь, вы понимаете, что FBD программы в такой ST код переводятся в режиме "что вижу, то пою"?
Для преобразования FBD в такой ST код нужно лишь объявить переменные с ФБ и присвоить входные-выходные значения.
Да, топологическую сортировку FBD, конечно, сделать придётся, но это вовсе не вопрос "где нужна доп ячейка, а где не нужна".

И, да, я ни строчки кода в компиляторе не менял. Просто добавил ФБ и создал программу с его участием.
Снимок экрана 2016-10-04 в 20.38.11.png

Вот результирующий ассемблер:

Снимок экрана 2016-10-04 в 20.38.49.png

"промежуточная" ячейка образовалась сама собой. R1.b1 (для первой обратной связи) и R1.b2 (для второй).

Ну, я, конечно, понимаю, что "с первого раза никогда ни одна программа не получается", но не вижу никаких сложностей с обратными связями. Честное слово не вижу.
Вот я написал простой ST, и он сразу заработал. В чём реально проблема?

Мой план -- FBD программы преобразовывать в ST, а потом обрабатывать уже имеющимся ST компилятором.
И наглядность FBD сохранится, и всегда можно будет проверить "во что оно превратилось" / "на каком этапе косяк".

На всякий случай, я использую следующие ключевые слова: dataflow analysis, live variable analysis, linear scan register allocation. Первые два алгоритма реализовывал не я, а они встроены в среду, на которой я пишу Hardella.


И, да, сейчас в ОЛ поведение "если есть цикл в программе, то разрывать его и где-то автоматически делать обратную связь", но, на мой взгляд, это нехорошее поведение. Если делать FBD в Hadrella, то я хотел запретить явные циклы, и всегда требовать от пользователя указания где именно связь с задержкой на такт.