Эх... Вот она путаница в терминах во всей красе...
"Адресный интерпретатор" и "Форт интерпретатор" - разные вещи. Хотя, в данном топике изначально речь шла именно об адресной интерпретации. Потому и непонятки вышли.
Для возврата в форт интерпретатор, проще всего, наверно, вызвать (INTERPRET) заново с остатком интерпретируемой строки в параметрах.
danbst писал(а):
Или лучше интепретатор тоже закодить на форте?
Кстати, вот это именно то решение, которое вполне подойдет, чтобы не ломать сильно голову. А для "простого" вызова форт-слов из ассемблера (ассемблерной имитации EXECUTE) придется делать специальную ассемблерную оболочку, которая по сути будет "адресным интерпретатором на одно слово", которая и сделает возврат в нужную точку.
Эх... Вот она путаница в терминах во всей красе...
"Адресный интерпретатор" и "Форт интерпретатор" - разные вещи. Хотя, в данном топике изначально речь шла именно об адресной интерпретации. Потому и непонятки вышли.
Для возврата в форт интерпретатор, проще всего, наверно, вызвать (INTERPRET) заново с остатком интерпретируемой строки в параметрах.
[quote="danbst"]Или лучше интепретатор тоже закодить на форте?[/quote]
Кстати, вот это именно то решение, которое вполне подойдет, чтобы не ломать сильно голову. А для "простого" вызова форт-слов из ассемблера (ассемблерной имитации EXECUTE) придется делать специальную ассемблерную оболочку, которая по сути будет "адресным интерпретатором на одно слово", которая и сделает возврат в нужную точку.
НО до входа в слово IP вообще не использовался (интепретатор - асемблерная процедура)! Как вернутся в процедуру (интепретатор) после NEXT? Или лучше интепретатор тоже закодить на форте?
Напишите INTERPRET на форте. Или втолкните на стек возвратов адрес трамплина, CFA которого вернет в ассемблер.
[quote="danbst"]НО до входа в слово IP вообще не использовался (интепретатор - асемблерная процедура)! Как вернутся в процедуру (интепретатор) после NEXT? Или лучше интепретатор тоже закодить на форте?[/quote] Напишите INTERPRET на форте. Или втолкните на стек возвратов адрес трамплина, CFA которого вернет в ассемблер.
Так ведь NEXT - это и есть возврат в интерпретатор!
EXECUTE вызывает слово. Если оно ассемблерное, то напрямую возвращается в адресный интерпретатор по NEXT.
Если фортовое, то оно сначала вызывает ENTER - новый вход в интерпретатор, a по EXIT выходит из него и по NEXT (из слова EXIT) вновь попадает в интерпретатор (который обслуживает то слово, что содержит EXECUTE)
Интерпретатор, конечно один на всех, просто ENTER - сохраняет текущий IP в стеке возвратов, который позже оттуда возвращается словом EXIT, и записывает в IP новый адрес... для вызываемого слова.
Так ведь NEXT - это и есть возврат в интерпретатор!
EXECUTE вызывает слово. Если оно ассемблерное, то напрямую возвращается в адресный интерпретатор по NEXT.
Если фортовое, то оно сначала вызывает ENTER - новый вход в интерпретатор, a по EXIT выходит из него и по NEXT (из слова EXIT) вновь попадает в интерпретатор (который обслуживает то слово, что содержит EXECUTE)
Интерпретатор, конечно один на всех, просто ENTER - сохраняет текущий IP в стеке возвратов, который позже оттуда возвращается словом EXIT, и записывает в IP новый адрес... для вызываемого слова.
Слово выполняется через NEXT. Доходит очередь до EXIT. Последний должен восстановить IP, который находился ДО входа в слово. НО до входа в слово IP вообще не использовался (интепретатор - асемблерная процедура)! Как вернутся в процедуру (интепретатор) после NEXT? Или лучше интепретатор тоже закодить на форте?
Хорошо, тогда так. Вход (режим интерпретации) [code] <вычисление CFA> EXECUTE <дальше слова>[/code] EXECUTE делает jmp mem(CFA)
Слово выполняется через NEXT. Доходит очередь до EXIT. Последний должен восстановить IP, который находился ДО входа в слово. НО до входа в слово IP вообще не использовался (интепретатор - асемблерная процедура)! Как вернутся в процедуру (интепретатор) после NEXT? Или лучше интепретатор тоже закодить на форте?
Еще вопрос. Как работает слово EXECUTE, вызванное с режима интерпретации при ITC? Дело в том, что адресный интепретатор в режиме интерпретации не используется, а слово EXIT делает jmp NEXT, а не ret (не возврящается в интерпретатор). Есть какое-то стандартное решение проблемы?
Еще вопрос. Как работает слово EXECUTE, вызванное с режима интерпретации при ITC? Дело в том, что адресный интепретатор в режиме интерпретации не используется, а слово EXIT делает jmp NEXT, а не ret (не возврящается в интерпретатор). Есть какое-то стандартное решение проблемы?
Смысл уже состоит в том, что если Хищник говорит, что удобно, а мне так не кажется, то пусть скажет еще что-нибудь по этому поводу. Может быть есть какая-то идея, которая лежит на поверхности, а я ее в упор не вижу. Так иногда бывает.
А что говорить-то? Существуют процессоры с гарвардской архитектурой, которые могут дописывать код в процессе работы. Если даже не могут дописывать, все равно остается кросс-компиляция, что позволяет использовать Форт, разрабатывая программы только на хост-машине. Разделение адресных пространств полезно хотя бы потому, что в ходе компиляции нет проблем с выполнением ALLOT - выделяемая память не пересекается с программным кодом. Если говорить о конфигурируемых процессорах, то вопрос вообще лишен смысла - почему вдруг нельзя описать память программ с доступом от процессора?
[quote="Ethereal"]Смысл уже состоит в том, что если Хищник говорит, что удобно, а мне так не кажется, то пусть скажет еще что-нибудь по этому поводу. Может быть есть какая-то идея, которая лежит на поверхности, а я ее в упор не вижу. Так иногда бывает.[/quote] А что говорить-то? Существуют процессоры с гарвардской архитектурой, которые могут дописывать код в процессе работы. Если даже не могут дописывать, все равно остается кросс-компиляция, что позволяет использовать Форт, разрабатывая программы только на хост-машине. Разделение адресных пространств полезно хотя бы потому, что в ходе компиляции нет проблем с выполнением ALLOT - выделяемая память не пересекается с программным кодом. Если говорить о конфигурируемых процессорах, то вопрос вообще лишен смысла - почему вдруг нельзя описать память программ с доступом от процессора?
На практике, тот Гарвард, что часто встречается, такой, что : - память, доступная для исполнения, недоступна для модификации - память, доступная для модификации, недоступна для исполнения Так-что правит бал какой-то неправильный Гарвард. Или таки правильный ? Так-что мысль про "удобнее всего" просто непонятна.
Существующие МК чаще всего ориентированы на кросс-компиляцию, при которой модификация программы в процессе работы попросту не нужна. В гарвардской архитектуре нет какого-то специального запрета на модификацию памяти программ в процессе работы. Однако если не обеспечивать доступ к памяти программ специально, то его не получится - идет постоянная выборка команд, в которую надо как-то вклиниваться. Это проблема не архитектуры, а технической реализации процессора.
[quote="Ethereal"]На практике, тот Гарвард, что часто встречается, такой, что : - память, доступная для исполнения, недоступна для модификации - память, доступная для модификации, недоступна для исполнения Так-что правит бал какой-то неправильный Гарвард. Или таки правильный ? Так-что мысль про "удобнее всего" просто непонятна.[/quote] Существующие МК чаще всего ориентированы на кросс-компиляцию, при которой модификация программы в процессе работы попросту не нужна. В гарвардской архитектуре нет какого-то специального запрета на модификацию памяти программ в процессе работы. Однако если не обеспечивать доступ к памяти программ специально, то его не получится - идет постоянная выборка команд, в которую надо как-то вклиниваться. Это проблема не архитектуры, а технической реализации процессора.
Блин, ну и зачем было выдумывать столь не по русски звучащий термин "токенезированный", коли такой тип ШК называется свернутым ? См. Баранов-Ноздрунов, например. В свернутом шитом коде адрес исполняемого кода слова представлен более коротким числом и вычисляется из этого числа по некоторому правилу. Индекс в таблице токенов - это частный случай.
Блин, ну и зачем было выдумывать столь не по русски звучащий термин "токенезированный", коли такой тип ШК называется свернутым ? См. Баранов-Ноздрунов, например. В свернутом шитом коде адрес исполняемого кода слова представлен более коротким числом и вычисляется из этого числа по некоторому правилу. Индекс в таблице токенов - это частный случай.
Смысл уже состоит в том, что если Хищник говорит, что удобно, а мне так не кажется, то пусть скажет еще что-нибудь по этому поводу. Может быть есть какая-то идея, которая лежит на поверхности, а я ее в упор не вижу. Так иногда бывает.
Смысл уже состоит в том, что если Хищник говорит, что удобно, а мне так не кажется, то пусть скажет еще что-нибудь по этому поводу. Может быть есть какая-то идея, которая лежит на поверхности, а я ее в упор не вижу. Так иногда бывает.
не понятна полемика. в пространстве, где можно исполнять располагаем ФВМ т.е. примитивы. выбираем косвенный или токенезированный ШК. вся форт-программа располагается в пространстве доступном на запись и чтение. Т.е. по сути делаем из гарвардской - форт машину.
понятно, что теряем в скорости и частично в использовании пространства, откуда код можно исполнять, но туда надо запихивать (и обычно хватает чего) всякие таблицы статические, вобщем константы разные туда.
не понятна полемика. в пространстве, где можно исполнять располагаем ФВМ т.е. примитивы. выбираем косвенный или токенезированный ШК. вся форт-программа располагается в пространстве доступном на запись и чтение. Т.е. по сути делаем из гарвардской - форт машину.
понятно, что теряем в скорости и частично в использовании пространства, откуда код можно исполнять, но туда надо запихивать (и обычно хватает чего) всякие таблицы статические, вобщем константы разные туда.