Forth
http://fforum.winglion.ru/

CREATE ... DOES>
http://fforum.winglion.ru/viewtopic.php?f=58&t=3241
Страница 1 из 1

Автор:  Victor__v [ Пн июл 01, 2019 12:05 ]
Заголовок сообщения:  CREATE ... DOES>

Пригодится при портировании и пр.

В Nova-forth при создании слова через CREATE или USER-CREATE всегда выделяется ячейка в кодофайле для DOES-кода.
Т.е.
код будет следующий
['] CREATE-CODE COMPILE,
['] NOOP , \ does-код по умолчанию.

Соот-но, при исполнении слова порождённого CREATE на стек данных будет укладываться указатель на пространство за ячейкой DOES-кода ( где NOOP в данном случае).

Преимущества такой реализации CREATE ... DOES>
  • простота
  • гибкость

Однако, другие форт-системы (СПФ в частности) устроены иначе - они модифицируют место вызова CREATE-CODE на соответсвующий код за DOES>

Поэтому при переносе наработок связанных со структурой CREATE нужно учитывать эту ячейку.
Некорректный код
Код:
CREATE TEST 30 ALLOT
' TEST >BODY


Корректный код
Код:
CREATE TEST 30 ALLOT
' TEST >param CELL+

Автор:  Hishnik [ Пн июл 01, 2019 18:18 ]
Заголовок сообщения:  Re: CREATE ... DOES>

После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.

Автор:  Victor__v [ Пн июл 01, 2019 19:39 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Hishnik писал(а):
После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.

Нифига не понял ваше сообщение. Расшифруйте, пожалуйста.
В моей реализации после скомпилированного вызова CREATE-CODE всегда выделяется память размером с CELL под возможные DOES>
CREATE-CODE при исполнении вызывает записанный в этой ячейке код.

Высокоуровневый вариант.
: CREATE-CODE R@ CELL+ R> @ >R ;

Автор:  Ethereal [ Пн июл 01, 2019 22:39 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Victor__v писал(а):
В Nova-forth при создании слова через CREATE или USER-CREATE всегда выделяется ячейка в кодофайле для DOES-кода.
Всегда - это в смысле будет ли после CREATE исполняться DOES> или не будет ? У слова просто созданного по голому CREATE эта ячейка тоже есть ?
Ну тогда >BODY должен переставлять указатель с поля кода на адрес сразу за этой ячейкой и абсолютная совместимость с SPF и любым ANSI или 83 Фортом в кармане. Потому что совместимость по базовым понятиям получается. У тебя просто получается, что поле параметров начинается сразу за этой ячейкой, что ты зарезервировал для возможного DOES>. CREATE должно возвращать адрес поля параметров и в этом поле еще ничего не должно быть распределено. Все выполняется.
А вот доступ к этой ячейке ВНУТРИ твоего Форта будет уже >BODY CELL-

У тебя интерфейс вовне какой ? Начиная с 83 суть слова определяется его полем кода. От этого поля дается переход к полю имени >NAME и к полю параметров >BODY . Ну и обратные переходы можно тоже сделать. Поле параметров - это еще не распределенное пространство должно быть. А вот какие еще ты ячейки зарезервировал в заголовках слов и чего там намутил это уже внутренняя кухня Форт-системы. Она сокрыта пока до нее специально дела кому-нибудь не будет.

Автор:  Hishnik [ Пн июл 01, 2019 22:55 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Victor__v писал(а):
В моей реализации после скомпилированного вызова CREATE-CODE всегда выделяется память размером с CELL под возможные DOES>
CREATE-CODE при исполнении вызывает записанный в этой ячейке код.

Можно ведь просто выделить память, сделав CREATE DATA[] 10000 ALLOT. Здесь не нужен DOES>, потому что DATA[] оказывается просто ссылкой на массив, и именно так и задумано. Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка. Или я что-то не так понял в описании.

Автор:  Ethereal [ Пн июл 01, 2019 23:01 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Hishnik писал(а):
Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка.
Именно так. Я уже писал в топике про систему КROL-а, что объединение смыслов CREATE и BUILDS> в одно понятие, что было сделано во времена 83 требует в общем случае не всегда используемой ячейки в заголовке слова. Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна. А вот в NOVA эта ячейка возникла не из-за того, что шитый код косвенный, а потому-что автор хотел гибкости и простоты. Но тоже таки возникла.
Если я все правильно понял в словах автора новы, конечно.
Ну потому-что CREATE требует нигде не распределенного, свободного еще поля параметров, а адрес кода для DOES> надо куда-то деть. Но в поле параметров нельзя, смысл CREATE не позволяет. Значит или в call вмонтировать или в одну не всегда используемую ячейку в заголовке слова сунуть.

Автор:  Victor__v [ Вт июл 02, 2019 01:06 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Hishnik писал(а):
Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка.

Я думал над такой несправедливостью и пришёл к выводу что на самом деле все равно выделяется ли доп. ячейка или нет.
При варианте с самомодификацией кода CREATE в начале DOES-кода всё равно надо прописывать -эм, достователь данных.

по поводу >BODY
У меня это слово называется >param . Считаю так правильней что ли.
Ну вот что значит >BODY ? Перейти к телу, какому телу? Имя не очень удачное.

Ещё с >BODY есть некоторые траблы.
В том же СПФ видел в либах как он используется для пропуска вызова кода. В частности, для констант, переменных и пр. Типа стандарт предполагает, жизнь располагает.
Ещё вопрос как >BODY должен работать со словами аналогичными CREATE. USER-CREATE к примеру. А если ещё подобных слов захочится. Не уж то делать это слово черезчур умным?
Да и ещё переход на 64 бита усложнит это слово.
Кажется, это неоправдано.

Ethereal писал(а):
А вот в NOVA эта ячейка возникла не из-за того, что шитый код косвенный, а потому-что автор хотел гибкости и простоты. Но тоже таки возникла.
Если я все правильно понял в словах автора новы, конечно.

Да, именно так.

При варианте с самомодификацией мы можем получить следующие неприятности:
на 64 битной архитектуре x86 длина кода вызова ем, нестабильна.
Это либо привычный CALL code
либо что-то вроде MOV RBX, code CALL RBX
Соот-но, если DOES-код и место вызова слова CREATE-CODE далеко-о друг от друга при перезаписи может возникнуть накладочка.

Другая проблема
Как при подобной самомодификации учитывать реализации CREATE для других пространств?
Вот хочется мне реализовать поточный вектор с действием по умолчанию
Код:
: U-VECT USER-CREATE CELL USER-ALLOT DOES> @ >R R@ 0= IF RDROP ." HELLO WORD" THEN ;

На том же СПФ слово порождённон таким кодом не запустится.


Цитата:
У тебя интерфейс вовне какой ?

Идентификатором слова служит его поле связи ( LFA ) оно у каждого слова своё и неповторимое при этом. Об этом ещё mOleg упоминал. Я пришёл к тем же выводам.
Насчёт хранения DOES-кода в словарной структуре, б-р :weep; да и в пространстве данных тоже не комильфо

Автор:  Ethereal [ Вт июл 02, 2019 01:18 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Victor__v писал(а):
Ещё вопрос как >BODY должен работать со словами аналогичными CREATE. USER-CREATE к примеру. А если ещё подобных слов захочится. Не уж то делать это слово черезчур умным?
Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, если формат заголовков для всех слов одинаков.
Victor__v писал(а):
В том же СПФ видел в либах как он используется для пропуска вызова кода. В частности, для констант, переменных и пр.
Не для пропуска кода, а для перехода на константу, переменную. Т.е. на поле параметров. А то, что это в точности пропускает код это уже внутренняя кухня и по счастливому совпадению. В частности если между кодом call-а и полем параметров еще слово воткнуто, то это обстоятельство только код на который call прыгает должен учитывать и только он. А для всех остальных есть только поле параметров и именно в поле параметров лежит константа, переменная или нераспределенная память HERE после CREATE
Victor__v писал(а):
Насчёт хранения DOES-кода в словарной структуре, б-р :weep; да и в пространстве данных тоже не комильфо
Где я такое говорил ? В словарной структуре указатель на DOES-код в том или ином виде, а не сам код.

Гы, заметил я за собой, что тоже употребляю термин "поле кода" в двух смыслах. Один правильный - поле в словарной статье, которое может содержать как call на код или указатель на код, так и быть началом самого кода. Только в таком толковании будет непротиворечиво. Так и неправильный - собственно само начало кода. ANSI-шники видимо тоже по этим граблям ходили и само начало кода обозвали xt - идентификатор (токен) исполнимого кода. Вот в правильном толковании поле кода тоже неповторимо для каждого слова, а ' и ['] возвращает не его, а исполнимый токен. Хотя эти вещи могут и совпадать.
Тогда >BODY в ANSI выходит это переход от исполнимого токена к полю параметров (а термин-то взят от совсем древних Фортов вроде ФИГа где он осязаыемый PFA). Но у SPF исполнимый токен (адрес куда передать управление для исполнения) и поле кода (поле в заголовке слованой статьи любым образом определяющее исполнимый токен) совпадают. Выходит так. Это я выходит свои мысли записываю.

Автор:  zma [ Вт июл 02, 2019 09:00 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Ethereal писал(а):
Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна.

Ну не прямо уж неизбежна:
DOES! - устанавливает CFA последнего определённого слова на <текущий адрес адресного интерпретатора>+2 ячейки
DOES> - компилирует DOES!, EXIT и машинный код, который кладёт PFA на стек и делает ENTER в высокоуровневое определение после себя (на этот машинный код и указывает поле кода создаваемого слова).
Недостаток - снижается портируемость, т.к. в определении DOES> появляется платформо-зависимый код.

Автор:  Victor__v [ Вт июл 02, 2019 20:43 ]
Заголовок сообщения:  Re: CREATE ... DOES>

Цитата:
Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, если формат заголовков для всех слов одинаков.

Причём тут формат заголовков? Каким он тут боком? Тупею видимо, через каждый 5 сообщений всё меньше понимаю :)
насчёт "константы" уже писал. на 32-битном интеле это прокатит, а вот на 64-битном может возникнуть неприятности.

Цитата:
В словарной структуре указатель на DOES-код в том или ином виде

А смысл? Его же все равно надо как-то вызывать.

Страница 1 из 1 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/