Задача сформирована Манулом, у которого есть техническая возможность выполнять операции, по эффекту соответствующие связкам слов Форта. Например, если не удалять число со стека, вместо СЛОВО будет DUP СЛОВО, но это не так интересно, как последовательности команд literal operation. Например, запись в переменную - это как раз последовательность действий такого вида. В целом, это все можно расширить и на обычные ВМ, реализуемые на ЯВУ, хотя там общий эффект и не будет так выражен (особо не нужно экономить память, а производительность определяется не интерпретатором команд ВМ).
Что приходит в голову:
1) Второй проход. Не очень хорошо, потому что его только что не было, а теперь из-за некрупного изменения появилось существенная модификация движка.
2) Явное указание связок в виде слов с отдельными именами.
2б) То же, но с автогенерацией соответствующего слова. Т.е. при создании переменной X сразу появляется слово X!, которое будет использовать литерал из команды и соответствующим образом компилироваться.
3) Анализ предыдущей команды, что потребует отмечать границы структур управления:



В целом, автогенерация "слов-обвязок" интересна и для ВМ, где можно X[] I -TH заменить на X[I], причем не определением Форта, а сразу в скомпилированном коде, что избавит от интерпретации трех отдельных слов. Работа с циклами в целом довольно заметна по времени.

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

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

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


Это и так можно сделать:

или

Тогда пользоваться можно X [I], что в принципе то же самое.

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

А вот это уже очень интересно! Тогда решается и вопрос со структурами управления, потому что они принудительно "сбросят" буфер в память. Причем туда и добавляться будет только то, что теоретически может быть сцеплено с чем-то последующим.. Видимо, это будет "пункт номер ноль" Попробую, выглядит красиво.

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

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

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

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

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

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

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

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

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

:) Надо бы еще монстров добавить. И финального босса, который часть скомпилированного кода рандомно меняет.

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

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

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