Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2019-08-18 12:54:35 ЛС | профиль | цитата
Nic писал(а):
Проект HiAsm.NET унаследовал проблему вызова бесконечной рекурсии при "кольцевании" схемы программы

Nic, вынужден возразить Вам дважды.

1) Кольцевание и рекурсия - это разные вещи. Рекурсия - это создание нового объекта (как некой копии оригинала) и применение к нему некого метода, с последующим его удалением.
Исторически термин рекурсия возник еще до ООП. Однако и там, при всяком рекурсивном обращении создавался объект в стеке, состоящий из входных аргументов и локальных переменных. А последующий код можно интерпретировать как некий метод этого объекта (EBP - указатель внутрь этого объекта).
Вспомните еще, что возможна иная, более эффективная генерация кода (передача аргументов через стек не есть догма). Можно в каком-нибудь регистре передавать адрес некой структуры в памяти, в которой нужные данные уже подготовлены. Типа, нафига десятками раз пихать в стек почти одни и те же данные в run-time. Так вот, если вы не будете при каждом рекурсивном обращении создавать такую структуру заново -- фиг вам, а не рекурсия.
Фортран, кстати говоря, так и делал, и, можете себе представить - не допускал рекурсий.
Можем ли мы решать рекурсивные задачи в HiAsm, запрещая (например, на уровне среды) кольцевания?
Конечно, если правильно понимаем, что такое рекурсия. У нас есть мультик в динамическом режиме, который создает экземпляр объекта при обращении, и удаляет экземпляр по окончании Грубо говоря, я - могу.
Показывал пример в виде сортировки (там ссылки на контейнер Sort - так это он и нарисован)
Рекурсивная сортировка

Вы можете соглашаться, или не соглашаться - от этого ничего не изменится. Потому что сказанное выше и есть Великая Сермяжная Правда

2) Кольцевание - если это и проблема, то больше семантическая. У нас просто нет договоренности как понимать некоторые вертиплясы с этим кольцеванием. А так - ну нет этой проблемы.
Например, такой вертипляс:
Add(Button,15697256,217,161)
{
Left=215
Top=160
link(onClick,8088855:doWork2,[])
}
Add(MultiElementEx,6238864,329,161)
{
Name="MX1"
link(2,120244:doEvent1,[])
}
BEGIN_SDK
Add(EditMultiEx,13251412,21,21)
{
WorkCount=#1:1|
EventCount=#1:2|
}
END_SDK
Add(MultiElementEx,3063538,448,168)
{
Name="MX2"
}
BEGIN_SDK
Add(EditMultiEx,16199070,21,21)
{
WorkCount=#1:1|
EventCount=#1:2|
}
END_SDK
Add(Hub,120244,399,161)
{
link(onEvent1,8088855:doWork1,[(424,167)(424,153)(284,153)])
link(onEvent2,3063538:1,[])
}
Add(HubEx,8088855,280,161)
{
@Hint=#35:Как спрашивается понимать эту фигню|
link(onEvent,6238864:1,[])
AddHint(-30,49,184,26,@Hint)
}
Мое личное мнение (не более того) состоит в том что вместо этого HubEx должен стоять некий другой системный элемент, который выполняет цикл, последовательно отправляя направо данные, которые ему напихали с боков. В какой последовательности напихали, в такой и отправлять.
Опять же среда (не эта, а некая перспективная) должна распознавать ситуацию кольцевания, и ставить вместо HubEx этот системный элемент без названия... Looper - как-то неприлично звучит.

Вот и все. Главное - у нас нет общей семантической договоренности. Если бы была - остальное не более чем технические вопросы.
карма: 9

0
Редактировалось 4 раз(а), последний 2019-08-18 13:01:10