Сообщение от
Дмитрий Артюховский
Это не правда. Транслятор с фбд вполне себе разбирается с высвобождением и переиспользованием регистров.
Вердикт: эксперимент показывает, что регистры _не_ переиспользуются. Тут всё ровно так, как и говорил Владислав.
Дмитрий, я требую извинений.
Вот пример: test_add.zip, pru_register_reuse.png
Видно, что после того, как первые AND'ы отрабатывают, то регистры можно и переиспользовать для следующих AND'ов.
Компилируем и видим такое (в конце):
Код:
#defFB PRU_AND2_64 PRU_AND2
R8.b2
R8.b3
R9.b0
#defFB PRU_AND2_59 PRU_AND2
R7.b1
R9.b0
R9.b1
#defFB PRU_AND2_65 PRU_AND2
R5.b2
R9.b1
R9.b2
Видно, что номера регистров только растут. Т.е. регистры с меньшими номерами не переиспользуются.
Пойдём в target.trg файл, и уменьшим значение REG_END=28 до 8-и. Ну, сделаем вид, что в нашем PRU всего-навсего 8 регистров.
Что нам скажет компилятор?
Он нам скажет "unknown ID 0 in element", и вообще не сможет скомпилировать такое FBD.
Т.е. по факту, компилятору не хватило R2..R8 регистров (7 штук по 4 байта каждый, т.е. 28 байт!).
А по факту, видно, что регистры для "AND" блоков очень быстро становятся ненужными.
По факту, тут 4 "FROM_HOST" блока. Да, 16 байт действительно нужно постоянно хранить (информация с HOST'а обновляется далеко не в каждом PRU цикле). Но остаётся целых 12 байт == 28-16, и линкер всё равно не смог выполнить несколько AND'ов? Что за ерунда?
Поэтому я и говорю, что мой подход и подход ОВЕН в части компиляции существенно отличаются.
Ну это я к чему, не к тому, что "инструмент beta PRU плохой", а к тому, что это моя аргументация почему я не могу просто взять и оформить свою ШД программу "по правилам ОВЕН". Тут не только моё субъективное "не хочу тратить время", но и вполне конкретная техническая проблема.
Ответить с цитированием