control-flow стек может быть как на стеке параметров, так и в отдельном. Стандарт ANS 94-го года предусматривает оба варианта.

Для отделения стека стуктур управления также есть решение ~mak/LIB/A_IF.F (instead of GOTO).


И это далеко не единственная открытая Америка. Есть ещё такое широко применяемое слово как MODULE:, которое тоже оставляет значение на стеке. Также, для большей независимости от поставленной перед компиляцией файла системы счисления часто пишут:

Ну и вообще мало смысла при стековой модели вычислений надеяться, что стек будет пуст при входе в какой-то блок кода.

с другой стороны можно отмечать глубину стека на момент входа и на момент входа куда либо, а затем сравнивать с тем, что на момент выхода изменилось

Ввел стек для использования при компиляции. Практически как у ProfiTa (только без глобальной переменной).
Таким способом можно вводить необходимое количество вспомогательных стеков.
Реализация:

лог-файл к примеру

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

Пока пример травопольного двойного прохода(с меткой вперед):

лог

Пока я не знаю как синтаксически оформить это как-то так(в Форте я не Адепт),

но думаю это не очень сложно будет - если еще кто-нибудь бы помог (из Адептов):D

Есть вопрос. Что-то я не нахожу готовых средств в СПФ для реализации 2-х проходной компиляции.
Нужно преобразовать 1-ю конструкцию во 2-ю:
WORD1 WORD2 .... WORDn и WORD1 WORD2 .... WORDn абсолютно одинаковые последовательности слов.
Может кто нибудь подскажет как такое сделать.

Кроме тебя, это кому-то нужно?

Михаил - спасибо. Я думаю будет нужно.
Интерпретатор может находиться в двух состояниях - компиляции и исполнения. Думаю нужно ввести еще одно состояние интерпретатора - формирование именованного отрезка входного потока.
В форуме этот вопрос уже обсуждался - не могу точто сказать когда и в каком топике(там по моему обсуждался вопрос о снятии ограничений на использование структур управления). Работа со словами, определенными в виде их исходных текстов даст дополнительные возможности при программировании(наверное каждый может их для себя определить).

После введения слов 2: и 2; - я их обозначу соответственно как L: и L; от слова LABEL определения с метками вводятся просто.
Пример:

лог

Набор слов управляющего стека: >CS, CS>, CS@, ?CSP, CSDROP, CSDEPTH (или CS-DROP, CS-DEPTH)
Аналогия: >R, R>, R@, RDROP.
См. Clarifications of Control-flow stack; Стандарт определяет лишь CS-PICK и CS-ROLL.

rvm - спасибо за наводку.

Простейшее решение — файл, он и есть именованный отрезок входного потока
Более сложное решение — использовать xml-based язык разметки (без вариантов).
Анонсирую: залил в SPF-репозиторий альфа-версию базового транслятора ForthML Управляющие конструкции в режиме исполнения — одно из требований к нему.

Под формированием именованного отрезка входного потока я подразумевал следующее:
По определенным словам во входном потоке интерпретатор переходит в режим формирования именованного отрезка входного потока, при котором следующее слово как имя вписывается в словарь, а следующие последовательности символов (до слов заканчивающих процесс формирования отрезка) вписываются в кодофайл. В дальнейшем эти "слова" могут использоваться по разному назначению(для компиляции, исполнения и для других целей). Слова, оканчивающие процесс формирования отрезков могут переводить интерпретататор
снова в режим формирования очередного отрезка или в режим компиляции или в режим исполнения.
Отрезки могут быть и неименованными с последующим присвоением им имени(как после :NONAME). При безименном формировании отрезков последовательность символов загоняется сначала в буфер, а потом уже после присвоения ей имени из буфера в словарь. Тут также возможны варианты с отделением имен от содержимого, соответствующих им отрезков.

Прикрутил дополнительный стек для нужд компиляции к ассемблеру.
Решил сделать этот ассемблер полностью постфиксным с целью сокращения его исходника. Писать будет немного не так удобно, но зато появляются дополнительные возможности конфигурирования машинных команд за счет более гибкого механизма передачи им параметров из программы.
Надо заметить, что ассемблер построен на I-словах(словах немедленного исполнения), поэтому может помещен
во временный словарь(его создавать нужно в куче), который перед исполнением SAVE может быть удален(освобожден).

Последние две строчки в слове TST демонстрируют полную независимость передачи параметров ассемблеру от состояния стека параметров.
лог-файл

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

О словах в виде исходных текстов.
T: NAME1 W1 W2 ... T;
T: NAME2 W3 W4 ... T;
T: NAME3 NAME1 NAME2 W4 W5 T;
T: - определение слова в виде текста
Выполняется аддитивный принцип наращивания семантической мощности, только не для кода(в Форте сделана попытка аддитивного наращивания семантической мощности на уровне кода - считаю, что это не совсем верно), а для исходных текстов. Для определенных аппаратных платформ (Х86 - это как раз тот случай) аддитивное наращивание семантической мощности на уровне кода дает неоптимальный код.
Слова можно изменять ( НАРАЩИВАТЬ )
T: NAME3 NAME3 W21 .. T;
Основной способ решения задач - конструирование оптимального синтаксиса(лексикона). Получение кода методом
контекстной компиляции - принцип аддитивности не соблюдается - код близок к оптимуму.