[quote="Victor__v"]Простейший пример создания правила:
RULE:
XT: DUP
XT: >R[/quote]
Вот наконец-то адекватный подход, а не жуть в spf-opt с условными операторами. Конечно, как временное решение или проверку концепции можно и вручную, но задание правил существенно полезнее и проще для сопровождения.

Мне, тем не менее, сейчас важнее поддержать команды форт-процессора, которые заранее спроектированы под пары базовых слов Форта. Там простые связки уровня dup <word> и lit <word>.

[quote]Кстати, надо еще, чтобы оптимизатор сам себя оптимизировал[/quote]
Не так уж и сложно. Просто 2 раза вызываем на компиляцию одну и ту же библиотеку. 2-я как раз будет оптимизированным оптимизатором, а 1-ю просто удаляем.

Ну вот, совсем другое дело :) А то некоторые говорят, что компиляторостроение - это скучно.
Кстати, надо еще, чтобы оптимизатор сам себя оптимизировал. Пока сингулярность не наступит. А то какой-то сапожник без сапог :) Лучше уж портниха без юбки, чем сапожник без сапог.

На роль монстров идут оптимизационные баги.
Финальным боссом будет оптимизатор уже скомпилированного кода, который модернезирует его на лету, находясь при этом в другом потоке.
:))

[quote="Victor__v"]Прикольная игрушка получилась.[/quote]:) Надо бы еще монстров добавить. И финального босса, который часть скомпилированного кода рандомно меняет.

У меня задаются правила оптимизации в виде дерева. Все это сделано отдельной либой и вешается на изначальные фичу моего форта (можно поставить обработчик на компиляцию любого слова).

Простейший пример создания правила:
RULE:
XT: DUP
XT: >R
>>>
0x50 C, \ PUSH RAX
;

Таким образом, если при компиляции встретится DUP обработчик подсмотрит какая там идёт дальше следующая лексема. Если это будет >R, то вместо компиляции двух слов будет выполнен код 0x50 C,

Прикольная игрушка получилась.

У меня отдельной утилитой разные оптимизации сделаны, чтобы не переусложнять транслятор форт-в-асм, а также потому, что в разных процессорах в общем случае нужны разные оптимизации, проще подставлять нужный "оптимизатор" в процессе трансляции, да и проще добавлять каждую новую оптимизацию в один-два оптимизатора, чем тиражировать эту же оптимизацию на все трансляторы под разные процессоры. Но вообще оптимизатор появился не для собственно оптимизаций (оно и не особо нужно, т.к., например, даже 6-битный в системе команд поддерживает только инкремент/декремент из числа таких операций), а чтобы подчищать хвосты за транслятором си-в-форт, т.к. его тоже принципиально не хочу переусложнять. Например, сишное присваивание <=> и последующий drop конвертируются в в swap !, становится 2 такта вместо нескольких. Или 12 + 4 + 1 + конвертируется в 17 +.

Ну да, это в каком-то смысле оптимизация, только локальная. Это надо форт-процессору, потому что иначе команда есть, а поддержки нет.

А... теперь понял.
Я себе таким образом оптимизатор кода делал)

[quote="Victor__v"]А теперь объясните мне на пальцах как это должно работать. Я кажись не до конца понял задумку.[/quote]
Например, если последовательность DUP @, которую можно заменить командой, с таким же итоговым эффектом (т.е. которая не снимает адрес со стека). Тогда встреченный DUP помещается во временный буфер, и идем дальше. Если следующая команда @, то она смотрит в буфер, и если находит там DUP, то вместе с ним "схлопывается" в команду DUP@. Если же это не @, а что-то еще, которому DUP не нужен, то DUP наконец-то компилируется, а новая команда заменяет его в буфере (вдруг с ней кто-то еще сможет образовать цепочку). Структуры управления должны "сбросить" буфер в память, поскольку они отмечают адреса для перехода, который при таких заменах произойдет куда-то в середину единственной команды (а никакой середины у нее нет).

[quote="Total Vacuum"]Еще вариант с буферизованным чтением можно рассмотреть.
Очередной прочитанный токен не компилируем сразу, а помещаем в кольцевой буфер на 2/3/и т.д (сколько нужно) токенов. Если буфер полон, то перед добавлением очередного токена удаляем (и компилируем) из него один или несколько (если совпало с каким-то из шаблонов) самых старых.
Например,[code]2 [ ] [2] пишем 2 в буфер
1 [2] [1] пишем 1 в буфер
+ [1] [+] пишем + в буфер, 2 из буфера удаляем и компилируем
3 [ ] [3] пишем 3 в буфер, 1 и + из буфера удаляем и компилируем в инкремент
eof [ ] [ ] данные закончились, компилируем остатки буфера, т.е. 3[/code][/quote]

А теперь объясните мне на пальцах как это должно работать. Я кажись не до конца понял задумку.

[quote="Total Vacuum"]Еще вариант с буферизованным чтением можно рассмотреть.[/quote]
А вот это уже очень интересно! Тогда решается и вопрос со структурами управления, потому что они принудительно "сбросят" буфер в память. Причем туда и добавляться будет только то, что теоретически может быть сцеплено с чем-то последующим.. Видимо, это будет "пункт номер ноль" :) Попробую, выглядит красиво.

Еще вариант с буферизованным чтением можно рассмотреть.
Очередной прочитанный токен не компилируем сразу, а помещаем в кольцевой буфер на 2/3/и т.д (сколько нужно) токенов. Если буфер полон, то перед добавлением очередного токена удаляем (и компилируем) из него один или несколько (если совпало с каким-то из шаблонов) самых старых.
Например,[code]2 [ ] [2] пишем 2 в буфер
1 [2] [1] пишем 1 в буфер
+ [1] [+] пишем + в буфер, 2 из буфера удаляем и компилируем
3 [ ] [3] пишем 3 в буфер, 1 и + из буфера удаляем и компилируем в инкремент
eof [ ] [ ] данные закончились, компилируем остатки буфера, т.е. 3[/code]

[quote="Victor__v"]Рассматривалась ли идея усложнить парсер слова?[/quote]
Парсер да, можно считать еще одним способом, только тут скорее архитектурные соображения. Начав разбирать "особые случаи", можно переусложнить парсер и дойти до гибридного синтаксиса, когда появятся и круглые скобки, и expressions, и прочее в таком роде.

Я сейчас придерживаюсь единственного исключения при разборе - кавычка отмечает начало строки, даже без пробела после нее. Это просто общепринятая запись, и видеть пробелы немного странновато и дезориентирующе (не говоря уже о S" и прочих странностях).

[quote="Victor__v"]Условно при встрече X[I] интерпретатор делит слово на переменную X и непонятную часть [I], эта часть ищется в отдельной таблице и при нахождении модифицирует поведение слова.[/quote]
Это и так можно сделать:
[code]: [I] I -TH ;[/code]
или
[code]: [I] I CELLS + ;[/code]
Тогда пользоваться можно X [I], что в принципе то же самое.

Рассматривалась ли идея усложнить парсер слова?
Условно при встрече X[I] интерпретатор делит слово на переменную [b]X[/b] и непонятную часть [b][I][/b], эта часть ищется в отдельной таблице и при нахождении модифицирует поведение слова.