точнее, тема поднятого вопроса будет наиболее актуальной


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

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

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

Думаю, нужно всё-таки сказть, что думаю. Разработка "минимального форта" - это на самом деле не есть что-то очень перспективное. К чему это приведёт? К освоению (офортению) старинного слабого процессора? Группы процессоров? Если это зачем-либо очень надо - нужно ставить более подробно требования и решать как задачу, общие рассуждения как раз в этом случае могут оказаться лишними. Если цель - урезать ЯЗЫК форт для более экономной реализации - это другой случай. А перспективным был бы путь - расширения и оптимизации форт-машины.

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

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

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

С другой стороны, существует разрядность шин, которую можно принять за простейшую типизацию. Кроме того, каждое форт-слово, состоящее из предыдущих, имеет тип самого себя. Другое дело, что не существует проверки во время исполнения. Это я так веду к вопросу: что помешает унификации языка для разных «железок»(кроме значения регистров в маш. кодах)?
Т.е. вариантов возможных структур много, а критерии выбора не определены. Тогда, полагаю, что можно исходить из перспектив унификации на основе построения типов?

именно об этом и речь.

вообще, поднятие с нуля нового Форта не такая уж тривиальная задача(как об этом любят говорить, другое дело, что другие ЯП реализовать еще сложнее), особенно, если вы ее решаете впервые. И дело не только в знании основ языка и понимании их работы. А что касается минимального набора, да еще с возможностью его дальнейшего "выращивания" в более полную систему, то все еще сложнее оказывается.


ну может хватит это повторять. ведь не верно.
в Форте нет "контроля типов" в явном виде, не более того!
с другой стороны в явном виде типы очень даже есть, например C@ B@ W@ F@ D@ F@ D+ и так далее.
то есть тип операнда кодируется в операции!!! это и есть основа 0-операндной вычислительной модели.

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

И для каждого процесоора - свой минимум - пусть mOleg представит процессор

И каковы, например, эти требования?


Да, и заманчивая... Но чем плох путь "минимизации" мне пока так и не понятно.

Можно. скажем так
3 (4) этапа
0 этап - создать минимум языка - т.е. убрать слова, которые ТОЧНО реализуются через другие
1 этап - оставшиеся слова - смотрим, как они реализуются одно через другое.
2 этап - смотрим, как слова реализуются в коде
3 этап - отбираем для реализации те слова, которые позволяют реализовать все остальные и проще других (вместе!) в коде

Ну раз нет типов, то и их контроля тоже нет.

Операции над данными не могут не быть нацеленными на определенный тип, но из этого не следует, что в Форте есть типы.
Основа 0-операндной вычислительной модели(точнее 0-адресной для операндов) состоит в том, что операнды не надо адресовать в операциях над ними. Для Форта это в реальности не выполняется, по простой причине - в нем нет канонического стека(вместо него массив ячеек с указателем).

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

и для каждой следующей аритектуры ВМ и для каждого след. процессора - заново

Возможно более интересная задача. точнее определить, что делать FVM
например в случае деления на 0.
Или метод перевода FVM в спящий режим, чтобы экономить энергию.

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