Ну, раз тебя эта тема волнует, то теорию стоит посмотреть
На сколько я помню курс в универе, классические компиляторы строят код в как-бы два прохода:
сначала преобразуют смешанную_запись ( если для си) в постфиксную. Исходя из постфиксной записи
генерируют четверки: источник1 источник2 команда получатель и эти четверки дальше распределяют
по регистрам. Там уже зависит от того, сколько есть регистров и на сколько они универсальны.
В форте первая часть оказыватеся пройдена без вмешательства компилятора, а вторую можно и не пропускать. для большинства базовых слов заранее изветсна стековая картинка - можно сгенерировать четверки, ну а с новыми словами посложнее, так как заранее не известно, соклько параметров они получат, а сколько отдадут(в этом плане классические ЯП проще), но здесь есть подозрение, что можно раскрутить слова, не содержащие ветвлений, а значит всегда получающие фиксированное кол-во параметров и отдающие тоже фиксированное кол-во параметров.


Я давно смотрел, на сколько хорошо оптимизатор работает. Так что претензий никаких
Сейчас просто он мне мешает, так как я эксперементирую с СПФом.
Поэтому я попросил его исключить, точнее сделать исключаемым. Размер у него приличный 8(



Это оригинальный код:
: SHEADER ( addr u -- )
HERE 0 , ( cfa )
DUP LAST-CFA !
0 C, ( flags )
-ROT WARNING @
IF 2DUP GET-CURRENT SEARCH-WORDLIST
IF DROP 2DUP TYPE ." isn't unique" CR THEN
THEN
CURRENT @ +SWORD
ALIGN
HERE SWAP ! ( заполнили cfa )
;

Я очень хочу, чтобы в дистрибутиве!!! этот код был изменен таким образом:

: SHEADER ( addr u -- )
HERE
0 OVER to_cfa !
0 OVER to_flags C!
....

И так далее. А так же все остальные слова, которые работают с полями слова.
Того же я хочу для словаря. То есть, нужно завести две структуры, которые будут описывать формат
словарной статьи и формат словаря и через них определить слова для работы с ними.
Я понятно объясняю?

Не хорошо работать с памятью, которая еще не выделена с помощью ALLOT.
А как ты при этом определишь такие слова как NAME>C NAME>F ?
У нас получается 2е базы.
В общем, я понял, что ты склонен ко 2му, предложенному мной варианту.
Я в общем тоже.
С применением -FIELD :
http://fforum.winglion.ru/viewtopic.php ... ight=#1996
Только я ошибся в src\tc_spf.f


В src\compiler\spf_wordlist.f следует переопределить NAME>F NAME>C
ради корректного определения /HD_-FLDS и NAME>


/HD_-FLDS - содержит размер структуры.

В src\compiler\spf_defwords.f



В src\compiler\spf_immed_transl.f
для использования -FIELD в рантайме:


Добавление полей в рантайме:

я говорил о принципе


вообще стоило бы сразу отвязаться от методики расположения полей в памяти. Может захочу в другую область вынести имена а в третью - поля связи? Думаю, что правильнее было бы это сделать через lfa и от него переходить на остальные поля. А связывать поля можно друг с другом отложенно, то есть сначала создать необходимые, потом заполнить адреса в lfa. Конечно кода за собой это повлечет чуточку больше, но зато сразу исчезнут все дальнейшие вопросы в этой области. Мне так кажется.



не совсем. Создавая еще одну структуру нужно заботиться о ее местоположении, а так можно располагать все там, где оно будет выглядеть естественно.

Я бы предложил такой вариант:
\ исполнимая часть слова состоит из поля кода и поля параметров
\ поле кода может иметь различный размер в зависимости от используемого
\ шитого кода. При использовании косвенного шитого кода это поле будет
\ равно token-у, при прямом шитом коде оно обычно равно размеру
\ команды CALL addr, при использовании подпрограммного шитого кода
\ это поле вообще не имеет фиксированного размера.

0 Struct: CFA
cfl record >cfa \ тут начинается поле кода
zero record >pfa \ тут начинается поле параметров
EndStruct

\ поле связи. Содержит ссылки на поле кода и на предыдущее слово
\ в словаре(обычно), но может так же содержать дополнительные адресные
\ поля, например, ускоряющие поиск слова.
\ поле code не обязательно, если сразу за заголовком идет код

0 Struct: LFA
token record code>
token record link>
EndStruct

\ аттрибуты слова
0 Funct: flag{
0 Bit immediate \ признак слова немедленного исполнения
1 Bit smudge \ признак сокрытого слова
2 Bit forbidden \ слово нельзя исполнять (более жесткий smudge)

3 Bit doesword \ слово создано с помощью DOES>
4 Bit codeword \ слово создано с помощью CODE
5 Bit vocabulary \ признак словаря

7 Bit --------- \ какие еще будут варианты?
: } ; Verb:
EndFunct

\ поле имени обычно включает в себя поле связи, содержит флаги и
\ имя слова, если слово именовано.

0 Struct: NFA
zero record name
EndStruct

0 Struct: header
LFA /size record >link
byte record >flag
NFA /size record >name
EndStruct

структура описана с использованием моей либы, можно не обращать внимания, я думаю все достаточно прозрачно и так


дА! Хотя бы так, но еще лучше, как я предложил выше
тогда вообще отвязываемся от типа кода и методики адресации памяти!


кстати за одно и код

WARNING @
IF 2DUP GET-CURRENT SEARCH-WORDLIST
IF DROP 2DUP TYPE ." isn't unique" CR THEN
THEN
вынести в отдельное слово: ?warning
опять у меня куча желаний

Ты хочешь использовать разные типы кода в одной системе?
Я еще забочусь о совместимости. При моем способе, все старые
поля остались на своих местах, а с новыми можно выделываться,
как хочешь.

Щас отвечу
Допустим, я хочу портировать спф на другой проц... Это первый ответ
Второй ответ еврейский: ?а что случится, если поля не останутся на месте? А? Перестануть работать хаки?!!
но это по-моему никого не должно волновать. Все остальное останется таким же! Максимум придется исправить пару мест в самом СПФ. Но на последнем я не настаиваю. Хотя бы то, что есть задокументировать!

И что с того? Единственное, что может потребоваться изменить это >BODY.



Я не могу гарантировать, что изменения словарной системы не на что не повлияют.
А главное людям придется лишний раз разбираться. И так многим не понятно.
Форт должен иметь примитивоное устройство. Словарная система СПФ достаточно
проста. Вообще, для изменения чего-либо в \src нужны очень весткие основания.



Оптимизатор тоже никого не должно волновать. Однако волнует.

на сколько знаю - не только


Михаил, сейчас мне не понятно (когда я смотрю в исходники ) как устроена словарная статья. Мне приходится с этим достаточно долго разбираться и убеждаться на своем опыте, в каких местах, например, не стоит добавлять поля. Добавление пары констант, описывающих формат словарной статьи форт-системы СПФ улучшит понимание работы ее. Мне ничего не говорит такое выражение:
0 ,
а вот если там будет:
0 to_cfa ! ( или 0 over to_cfa ! )
я пойму сразу. И еще наличие констант, находящихся отдельно и описанных в одном месте приводят к тому, что любое расширение слованой статьи не запорет систему ( мне соверенно не интересно разбираться как ищет слова та или иная система - мне только нужно добавить свое и с ним работать.

Да! Должна быть проста! Но и понятна! Сейчас она не проста и не понятна.

Она проста. Просто на нее нет красиво разрисованной картинки.

Я воспринял критику и сам полез в спф. Начал со словарей.
И сразу наткнулся на:
: WORDLIST ( -- wid ) \ 94 SEARCH
HERE VOC-LIST @ , VOC-LIST ! \ -- 15-08-2006 просто односвязный список
HERE 0 , \ здесь будет указатель на имя последнего слова списка
0 , \ здесь будет указатель на имя списка для именованых
0 , \ wid словаря-предка
0 , \ класс словаря = wid словаря, определяющего свойства данного
;
!! WORDLIST возвращает не адрес поля voc-link а адрес поля last_word для этого словаря.
Не то, чтобы это сразу очевидн ( по крайней мере мне понадобилось два раза запустить собранную систему для проверки, чтоб понять, где моя ошибка.

Вот вой вариант:
\ 15-08-2006 начинаю модификацию словаря
\ структура словаря:
0 4 OVER + SWAP CONSTANT VocBackLink
4 OVER + SWAP CONSTANT VocLastWord
4 OVER + SWAP CONSTANT VocName
4 OVER + SWAP CONSTANT VocParentID
4 OVER + SWAP CONSTANT VocClass
CONSTANT #VocRec


\ Создает новый пустой список слов, возвращая его идентификатор wid.
\ Новый список слов может быть возвращен из предварительно распределенных
\ списков слов или может динамически распределяться в пространстве данных.
\ Система должна допускать создание как минимум 8 новых списков слов в
\ дополнение к имеющимся в системе.
: WORDLIST ( -- wid ) \ 94 SEARCH
\ 15-08-2006 моя правка:
HERE #VocRec ALLOT \ зарезервировали место под словарь
VOC-LIST @ OVER VocBackLink + !
DUP VOC-LIST ! \ связали в список
0 OVER VocLastWord + !
0 OVER VocName + !
0 OVER VocParentID + !
0 OVER VocClass + !
VocLastWord +
;
идем дальше:

\ для временных словарей дополнительные переменные:
\ 0 , \ адрес загрузки временного словаря (адрес привязки)
\ 0 , \ версия ядра, которой скомпилирован временный словарь
\ 0 , \ DP временного словаря (текущий размер)

\ создаст временный словарь (в виртуальной памяти)
: TEMP-WORDLIST ( -- wid )
WL_SIZE ALLOCATE THROW DUP >R WL_SIZE ERASE
-1 R@ ! \ не присоединяем к VOC-LIST, заодно признак временности словаря
R@ R@ 5 CELLS + !
VERSION R@ 6 CELLS + !
R@ 8 CELLS + DUP CELL- !
R> CELL+ ;
много ли здесь понятно с первого взгляда?
мне не понятно, например, зачем очищать словарь предед использованием?
А если я очень часто буду создавать и удалять такие словари( как делает, если я не ошибаюсь, locals.f )?
второй вопрос - а какие поля инициализируются? вычислять надобно? шас начну.
5 CELLS + = это наверное, наверное ( а сколько всего полей -то ) ага, у статических словарей 5.
значит "адрес загрузки временного словаря" дальше проще?

Как же так? Это же стандартные слова форта!
Компиляция нуля на вершину словаря, т.е. резервирование одной ячейки (для чего-то).

Бррр!!!рр
читайте в контексте!

что значит 0 , ???? - что тут должно быть? адрес? число? ключ? что именно?!!!

Или я опять чего-то недопонял?
P.S. ладно, мне уже убегать пора...

Не хотелось бы Вас разочаровывать, но написанное Вами на порядок непонятнее чем
HERE
0 , 0 , 0 , 0 , ;

Если Вам захотелось все-же обозвать поля заголовка словаря, то лучше всего что-то типа

: VocLastWord ( wid -- VocLastWord ) ;
: VocName ( wid -- VocName ) 4 + ; ( или CELL + ; )

И хотя VocLastWord стоит в самом конце совсем не очевидно, что это wid. Причина - приходится отслеживать стековую нотацию всего вышестоящего для поиска того с чем же складывается VocLastWord , а там в каждой строке работа как минимум с тремя уровнями стека.
У меня обычно при разборе таких записей пар из ушей валит.

Больше чем в Вашем варианте . Хотя здесь применен именно он, но без OVER.
Сразу понятно, что wid это то, что вернуло ALLOCATE + CELL ( 4 ) т.к. найти >R не составляет проблем.
Мой бы вариант был не сильно отличающийся. Разве что чуть подправил отступы


На всякий пожарный . Там ведь изначально мусор...По сравнению со временем ALLOCATE это просто мизер.
Тут собственно вопрос спорный. Бо в 99,999% случаев знать поля заголовка словаря и даром не надо, при этом в 99% знать эти поля вредно - программа становится зависимой от реализации. О заголовке надо знать только одно - он идентифицируется wid ( так-же как слово - xt ). Все, что работает с заголовком должно работать через wid.

?я не разочаруюсь, в чем сложнее и почему на порядок?


можно и так. Но в моем случае смещения расчитываются автоматически
последовательность: OVER + SWAP CONSTAN можно заменить на
: field: OVER + SWAP CONSTANT ;
тогда текст будет чище. Но сути это не изменит.


здесь не понял утверждения 8(
причем тут отслеживание стековой нотации?
есть всего лишь один базовый адрес!
Сейчас в спф есть структура, которая неявно существует и очень сильно соопротивляется модификации, к тому же действия над ней достаточно сложно отслеживать.



а что делают остальные поля и где они распологаются? что такое 6 cells + ? что будет, если я захочу добавить еще одно поле? убрать лишнее?

Ну и что, что мусор?


но за счет этого и без того тормозной спф тормозит еще больше?
зачем делать лишнюю работу?

хорошо, давайте делать каждый свой форт и будем счастливы. Мне понадобилось уже несколько раз (при переносе либ со смал32 на спф ) залезть в структуру словаря 8( я использую такую практику. И я натыкаюсь на немодифицируемый код, то есть его конечно можно модифицировать, но для этого нужно весь форт перебрать потратив на это достаточно времени, вместо того, чтобы просто добавить еще одно поле в структуру?!

С этого и надо было начинать. Проблему нужно представить, как она есть.
Только нужно еще конкретнее. А то ты предлогаешь решение проблемы,
о которой люди не в курсе.
Подобное происходит постоянно.