Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 22:52

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - CREATE ... DOES>
Автор Сообщение
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
Цитата:
Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, если формат заголовков для всех слов одинаков.

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

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

А смысл? Его же все равно надо как-то вызывать.
Сообщение Добавлено: Вт июл 02, 2019 20:43
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
Ethereal писал(а):
Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна.

Ну не прямо уж неизбежна:
DOES! - устанавливает CFA последнего определённого слова на <текущий адрес адресного интерпретатора>+2 ячейки
DOES> - компилирует DOES!, EXIT и машинный код, который кладёт PFA на стек и делает ENTER в высокоуровневое определение после себя (на этот машинный код и указывает поле кода создаваемого слова).
Недостаток - снижается портируемость, т.к. в определении DOES> появляется платформо-зависимый код.
Сообщение Добавлено: Вт июл 02, 2019 09:00
  Заголовок сообщения:  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 исполнимый токен (адрес куда передать управление для исполнения) и поле кода (поле в заголовке слованой статьи любым образом определяющее исполнимый токен) совпадают. Выходит так. Это я выходит свои мысли записываю.
Сообщение Добавлено: Вт июл 02, 2019 01:18
  Заголовок сообщения:  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; да и в пространстве данных тоже не комильфо
Сообщение Добавлено: Вт июл 02, 2019 01:06
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
Hishnik писал(а):
Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка.
Именно так. Я уже писал в топике про систему КROL-а, что объединение смыслов CREATE и BUILDS> в одно понятие, что было сделано во времена 83 требует в общем случае не всегда используемой ячейки в заголовке слова. Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна. А вот в NOVA эта ячейка возникла не из-за того, что шитый код косвенный, а потому-что автор хотел гибкости и простоты. Но тоже таки возникла.
Если я все правильно понял в словах автора новы, конечно.
Ну потому-что CREATE требует нигде не распределенного, свободного еще поля параметров, а адрес кода для DOES> надо куда-то деть. Но в поле параметров нельзя, смысл CREATE не позволяет. Значит или в call вмонтировать или в одну не всегда используемую ячейку в заголовке слова сунуть.
Сообщение Добавлено: Пн июл 01, 2019 23:01
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
Victor__v писал(а):
В моей реализации после скомпилированного вызова CREATE-CODE всегда выделяется память размером с CELL под возможные DOES>
CREATE-CODE при исполнении вызывает записанный в этой ячейке код.

Можно ведь просто выделить память, сделав CREATE DATA[] 10000 ALLOT. Здесь не нужен DOES>, потому что DATA[] оказывается просто ссылкой на массив, и именно так и задумано. Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка. Или я что-то не так понял в описании.
Сообщение Добавлено: Пн июл 01, 2019 22:55
  Заголовок сообщения:  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 . Ну и обратные переходы можно тоже сделать. Поле параметров - это еще не распределенное пространство должно быть. А вот какие еще ты ячейки зарезервировал в заголовках слов и чего там намутил это уже внутренняя кухня Форт-системы. Она сокрыта пока до нее специально дела кому-нибудь не будет.
Сообщение Добавлено: Пн июл 01, 2019 22:39
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
Hishnik писал(а):
После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.

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

Высокоуровневый вариант.
: CREATE-CODE R@ CELL+ R> @ >R ;
Сообщение Добавлено: Пн июл 01, 2019 19:39
  Заголовок сообщения:  Re: CREATE ... DOES>  Ответить с цитатой
После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.
Сообщение Добавлено: Пн июл 01, 2019 18:18
  Заголовок сообщения:  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+
Сообщение Добавлено: Пн июл 01, 2019 12:05

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB