Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: CREATE ... DOES> |
|
|
Цитата: Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, если формат заголовков для всех слов одинаков. Причём тут формат заголовков? Каким он тут боком? Тупею видимо, через каждый 5 сообщений всё меньше понимаю насчёт "константы" уже писал. на 32-битном интеле это прокатит, а вот на 64-битном может возникнуть неприятности. Цитата: В словарной структуре указатель на DOES-код в том или ином виде А смысл? Его же все равно надо как-то вызывать.
[quote]Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, если формат заголовков для всех слов одинаков.[/quote] Причём тут формат заголовков? Каким он тут боком? Тупею видимо, через каждый 5 сообщений всё меньше понимаю :) насчёт "константы" уже писал. на 32-битном интеле это прокатит, а вот на 64-битном может возникнуть неприятности.
[quote]В словарной структуре указатель на DOES-код в том или ином виде[/quote] А смысл? Его же все равно надо как-то вызывать.
|
|
|
|
Добавлено: Вт июл 02, 2019 20:43 |
|
|
|
|
|
Заголовок сообщения: |
Re: CREATE ... DOES> |
|
|
Ethereal писал(а): Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна. Ну не прямо уж неизбежна: DOES! - устанавливает CFA последнего определённого слова на <текущий адрес адресного интерпретатора>+2 ячейки DOES> - компилирует DOES!, EXIT и машинный код, который кладёт PFA на стек и делает ENTER в высокоуровневое определение после себя (на этот машинный код и указывает поле кода создаваемого слова). Недостаток - снижается портируемость, т.к. в определении DOES> появляется платформо-зависимый код.
[quote="Ethereal"]Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна.[/quote] Ну не прямо уж неизбежна: 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-кода в словарной структуре, б-р да и в пространстве данных тоже не комильфо Где я такое говорил ? В словарной структуре указатель на DOES-код в том или ином виде, а не сам код. Гы, заметил я за собой, что тоже употребляю термин "поле кода" в двух смыслах. Один правильный - поле в словарной статье, которое может содержать как call на код или указатель на код, так и быть началом самого кода. Только в таком толковании будет непротиворечиво. Так и неправильный - собственно само начало кода. ANSI-шники видимо тоже по этим граблям ходили и само начало кода обозвали xt - идентификатор (токен) исполнимого кода. Вот в правильном толковании поле кода тоже неповторимо для каждого слова, а ' и ['] возвращает не его, а исполнимый токен. Хотя эти вещи могут и совпадать. Тогда >BODY в ANSI выходит это переход от исполнимого токена к полю параметров (а термин-то взят от совсем древних Фортов вроде ФИГа где он осязаыемый PFA). Но у SPF исполнимый токен (адрес куда передать управление для исполнения) и поле кода (поле в заголовке слованой статьи любым образом определяющее исполнимый токен) совпадают. Выходит так. Это я выходит свои мысли записываю.
[quote="Victor__v"]Ещё вопрос как >BODY должен работать со словами аналогичными CREATE. USER-CREATE к примеру. А если ещё подобных слов захочится. Не уж то делать это слово черезчур умным?[/quote]Да во всех случаях : >BODY константа + ; или аналогиное с фиксированным смещением, [b]если формат заголовков для всех слов одинаков[/b].[quote="Victor__v"]В том же СПФ видел в либах как он используется для пропуска вызова кода. В частности, для констант, переменных и пр.[/quote]Не для пропуска кода, а для перехода на константу, переменную. Т.е. на поле параметров. А то, что это в точности пропускает код это уже внутренняя кухня и по счастливому совпадению. В частности если между кодом call-а и полем параметров еще слово воткнуто, то это обстоятельство только код на который call прыгает должен учитывать и только он. А для всех остальных есть только поле параметров и именно в поле параметров лежит константа, переменная или нераспределенная память HERE после CREATE [quote="Victor__v"]Насчёт хранения DOES-кода в словарной структуре, б-р :weep; да и в пространстве данных тоже не комильфо[/quote]Где я такое говорил ? В словарной структуре указатель на 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-кода в словарной структуре, б-р да и в пространстве данных тоже не комильфо
[quote="Hishnik"]Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка.[/quote] Я думал над такой несправедливостью и пришёл к выводу что на самом деле все равно выделяется ли доп. ячейка или нет. При варианте с самомодификацией кода CREATE в начале DOES-кода всё равно надо прописывать -эм, достователь данных.
по поводу >BODY У меня это слово называется >param . Считаю так правильней что ли. Ну вот что значит >BODY ? Перейти к телу, какому телу? Имя не очень удачное.
Ещё с >BODY есть некоторые траблы. В том же СПФ видел в либах как он используется для пропуска вызова кода. В частности, для констант, переменных и пр. Типа стандарт предполагает, жизнь располагает. Ещё вопрос как >BODY должен работать со словами аналогичными CREATE. USER-CREATE к примеру. А если ещё подобных слов захочится. Не уж то делать это слово черезчур умным? Да и ещё переход на 64 бита усложнит это слово. Кажется, это неоправдано.
[quote="Ethereal"]А вот в NOVA эта ячейка возникла не из-за того, что шитый код косвенный, а потому-что автор хотел гибкости и простоты. Но тоже таки возникла. Если я все правильно понял в словах автора новы, конечно.[/quote] Да, именно так.
При варианте с самомодификацией мы можем получить следующие неприятности: на 64 битной архитектуре x86 длина кода вызова ем, нестабильна. Это либо привычный CALL code либо что-то вроде MOV RBX, code CALL RBX Соот-но, если DOES-код и место вызова слова CREATE-CODE далеко-о друг от друга при перезаписи может возникнуть накладочка.
Другая проблема Как при подобной самомодификации учитывать реализации CREATE для других пространств? Вот хочется мне реализовать поточный вектор с действием по умолчанию [code] : U-VECT USER-CREATE CELL USER-ALLOT DOES> @ >R R@ 0= IF RDROP ." HELLO WORD" THEN ; [/code] На том же СПФ слово порождённон таким кодом не запустится.
[quote]У тебя интерфейс вовне какой ?[/quote] Идентификатором слова служит его поле связи ( LFA ) оно у каждого слова своё и неповторимое при этом. Об этом ещё mOleg упоминал. Я пришёл к тем же выводам. Насчёт хранения DOES-кода в словарной структуре, б-р :weep; да и в пространстве данных тоже не комильфо
|
|
|
|
Добавлено: Вт июл 02, 2019 01:06 |
|
|
|
|
|
Заголовок сообщения: |
Re: CREATE ... DOES> |
|
|
Hishnik писал(а): Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка. Именно так. Я уже писал в топике про систему КROL-а, что объединение смыслов CREATE и BUILDS> в одно понятие, что было сделано во времена 83 требует в общем случае не всегда используемой ячейки в заголовке слова. Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна. А вот в NOVA эта ячейка возникла не из-за того, что шитый код косвенный, а потому-что автор хотел гибкости и простоты. Но тоже таки возникла. Если я все правильно понял в словах автора новы, конечно. Ну потому-что CREATE требует нигде не распределенного, свободного еще поля параметров, а адрес кода для DOES> надо куда-то деть. Но в поле параметров нельзя, смысл CREATE не позволяет. Значит или в call вмонтировать или в одну не всегда используемую ячейку в заголовке слова сунуть.
[quote="Hishnik"]Можно, конечно, выделить память для будущего DOES> заранее, но тогда при отсутствии DOES> получается, что там просто лишняя ячейка.[/quote]Именно так. Я уже писал в топике про систему КROL-а, что объединение смыслов CREATE и BUILDS> в одно понятие, что было сделано во времена 83 требует [u]в общем случае[/u] не всегда используемой ячейки в заголовке слова. Без этой ячейки можно легко обойтись при любом шитом коде, кроме косвенного, но вот при косвенном она совершенно неизбежна. А вот в 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> получается, что там просто лишняя ячейка. Или я что-то не так понял в описании.
[quote="Victor__v"]В моей реализации после скомпилированного вызова CREATE-CODE всегда выделяется память размером с CELL под возможные DOES> CREATE-CODE при исполнении вызывает записанный в этой ячейке код.[/quote] Можно ведь просто выделить память, сделав 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 . Ну и обратные переходы можно тоже сделать. Поле параметров - это еще не распределенное пространство должно быть. А вот какие еще ты ячейки зарезервировал в заголовках слов и чего там намутил это уже внутренняя кухня Форт-системы. Она сокрыта пока до нее специально дела кому-нибудь не будет.
[quote="Victor__v"]В Nova-forth при создании слова через CREATE или USER-CREATE [b][i][u]всегда[/u][/i][/b] выделяется ячейка в кодофайле для DOES-кода.[/quote]Всегда - это в смысле будет ли после CREATE исполняться DOES> или не будет ? У слова просто созданного по голому CREATE эта ячейка тоже есть ? Ну тогда >BODY должен переставлять указатель с поля кода на адрес сразу за этой ячейкой и абсолютная совместимость с SPF и любым ANSI или 83 Фортом в кармане. Потому что совместимость по базовым понятиям получается. [b]У тебя просто получается, что поле параметров начинается сразу за этой ячейкой, что ты зарезервировал для возможного DOES>. CREATE должно возвращать адрес поля параметров и в этом поле еще ничего не должно быть распределено.[/b] Все выполняется. А вот доступ к этой ячейке ВНУТРИ твоего Форта будет уже >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 ;
[quote="Hishnik"]После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.[/quote] Нифига не понял ваше сообщение. Расшифруйте, пожалуйста. В моей реализации после скомпилированного вызова CREATE-CODE всегда выделяется память размером с CELL под возможные DOES> CREATE-CODE при исполнении вызывает записанный в этой ячейке код.
Высокоуровневый вариант. : CREATE-CODE R@ CELL+ R> @ >R ;
|
|
|
|
Добавлено: Пн июл 01, 2019 19:39 |
|
|
|
|
|
Заголовок сообщения: |
Re: CREATE ... DOES> |
|
|
После CREATE не обязательно должен идти DOES>. Логично DOES> подстраивать под существующее поведение CREATE, а не наоборот.
После 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+
Пригодится при портировании и пр.
В Nova-forth при создании слова через CREATE или USER-CREATE [b][i][u]всегда[/u][/i][/b] выделяется ячейка в кодофайле для DOES-кода. Т.е. код будет следующий ['] CREATE-CODE COMPILE, ['] NOOP , \ does-код по умолчанию.
Соот-но, при исполнении слова порождённого CREATE на стек данных будет укладываться указатель на пространство за ячейкой DOES-кода ( где NOOP в данном случае).
Преимущества такой реализации CREATE ... DOES> [list] [*] простота [*] гибкость[/list]
Однако, другие форт-системы (СПФ в частности) устроены иначе - они модифицируют место вызова CREATE-CODE на соответсвующий код за DOES>
Поэтому при переносе наработок связанных со структурой CREATE нужно учитывать эту ячейку. Некорректный код [code] CREATE TEST 30 ALLOT ' TEST >BODY [/code]
Корректный код [code] CREATE TEST 30 ALLOT ' TEST >param CELL+ [/code]
|
|
|
|
Добавлено: Пн июл 01, 2019 12:05 |
|
|
|
|