обсуждение наброска стандарта вынесено в отдельную тему



нехорошо это однако...
а если надо переход по таблице устроить, а с адресом ни AND, ни ADD не работает?..

почему же? проблемы возникают только в случае, если адреса больше разрядности данных.
если адрес двойной(и более) длины, а младшая часть адреса лежит сверху, то можно и ADD и AND (это как страничная адресация, получится).

Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются,
и после этого все операции работают, a в обратную сторону truncated... и все...

А заявление, что "могут не работать" - дико сбивает с толку...

интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше

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

вобщем да, но по сути эти моменты должны быть описаны где-то в параграфе 3 или 4

что касалось "могут не работать" то имелось ввиду, что работать не так, а не вообще не работать.

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

варианты:
float-point стек - де-факто уже есть в x86 системах.
стек для организации циклов - встречается.

Но это, имхо, стоит делать в виде расширения к стандарту, а не валить все в одно место.

добавление в 5. Первый уровень языка - ФВМ

А в каком наборе будет INTERPRET или EVALUATE?

только "должно быть", тут.
А так второй

Ок. Понял.

И еще попутно вопрос... Если рассматривать создание Форт-среды по данному стандарту с нуля, не с Форта 3.х. Какую часть стандарта придется писать в машиных командах (или на другом языке, с последующей компиляцией), а какую уже можно будет продолжать на самом Форте? И будет ли впоследствии замена предыдущего кода (написанного на машинном языке) кодом на Форте? Если "да", то до какого предела?

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

Специализация и универсальность, как обычно, почти полностью противоположны.

Если при раскрутке Форт системы используется, в той или иной степени, техника оптимизации определений под целевую
архитектуру, то и эти следующие "простые" определения не обязательно реализовывать на ассемблере. Особенно это может касаться
определений, которые, например, проводят процесс компиляции и в непосредственной дальнейшей работе результирующего
кода не задействованы при этом. Их может оказаться выгодным, в целях уменьшения размера кода, вообще не подвергать оптимизации
для целевого CPU во встроенной Форт системе. Реализации Форт слов, в разных Форт системах, бывает сильно отличаются и характеризуется
принятыми проектными решениями и ограничениями целевого CPU.

P.S. В SPF4, например, встроен макро-оптимизатор и код многих Форт слов, при самосборке, вполне адекватен предполагаемому результату.
Можно посмотреть и сравнить что получается на выходе и при желании доработать макрооптимизатор.

Минимум - 3 команды ... Если есть запись в память и возможность из нее выполнять код.
У меня для раскрутки пришлось сделать меньше десятка команд и несколько переменных.
Потом компилятор Forth-на-Forth-е (ну, на самом деле colorForth), который работает одновременно с интерпретатором. Когда в 64Кб откомпилировалась третья система, стало неудобно отлаживать... Пошел искать инструменты получше. До сих пор ищу... Периодически, правда, порываюсь сам сделать...