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


колибри в данном случае вообще не пример, к тому же сама по себе эта самая колибри ничего интересного не имеет.


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


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

Подобная задача вставала передо мной раз пять за те ~15 лет, пока я активно работал с Фортом. Через этап поиска "универсального Форта" я проскочил достаточно быстро, просто потому, что при осмысливании его возможной архитектуры сразу вспоминались те различия, которыми обладает весь зоопарк только основных разновидностей процессоров и МК.

Чтобы она была самодостаточной, в нее необходимо вставить массу настроек. И потом для каждого нового МК проверять, правильно ли обходится с ним эта "самодостаточная" система.

На реальную задачу и нужен реальный набор слов. А пока реальной задачи нет, можно очень долго и безрезультатно придумывать спецификации. Безрезультатно - потому, что каждый набор слов, написанный с прицелом на непонятно кого, будет регулярно переписываться просто так. А уж когда пойдет реальная работа, тем более обнаружится, что куча времени угроблена на попытки поддержать какую-нибудь ерунду, а основные функции реализовать нечем.

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

Секрет что-ли? Может уже есть готовая форт-система.




Си ассемлер есть?

Для получения примитивов с помощью Си, достаточно посмотреть
во что скомпилируются программа типа.



Определения форт-слов на форте можно посмотреть на
http://fpauk.narod.ru/GFWORDS.HTML
В http://www.google.com/codesearch
в поиске
umod lang:forth
cmove lang:forth
и т.д.

http://www.google.com/codesearch/p?hl=r ... lang:forth

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

DUP 03 / comment
SWAP 04 /coment

создает таблицу в памяти, итд.
Потом, после созлания асемблера для ФВМ, уже
можно будет разворачивать

Не уяснив постановку задачи. Слово "минимальный" подвело и необходимость предложить что-то не видя платформы.
Слово "минимальный" отсылает к математике - возникли иллюзия необходимости доказательного решения

см. мой следующий постинг

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

Представим себе, что у нас есть простой (воображаемый) язык, предполагающий только 2 команды – скажем, бежать и прыгать. Такого языка достаточно, чтобы программировать поведение игрушки (виртуальной или реальной), которая наделена только этими способностями. Понятно, что в этом случае минимальный компилятор должен уметь воспринимать 2 команды, некоторым образом складывая их в цепи. Казалось бы, всё ясно. Перед нами действительно минимальный компилятор. Но, действительно ли? Каким образом этот компилятор воспринимает команды? Читает ли он строки, умеет ли их переносить, воспринимает ли он ошибки или, скажем, неоднозначности? Что он делает при обнаружении ошибки – является ли способность остановиться перед ошибкой частью компилятора или нет? Может быть тогда минимальный компилятор – это такой, который компилирует 2 слова и распознаёт одну ошибку ( «ни одно слово не подходит») ? Или мы должны представить себе текст без ошибок и минимальный компилятор не должен быть способен на их распознавание? Понятно, что минимальный язык, пожалуй, не должен включать в себя слова для ошибок , а вот компилятор, не распознающий ошибок – компилятор ли это? Тот же вопрос об исключениях?
Вернёмся к чтению строк – должен ли минимальный компилятор включать функцию чтения строк? Должен ли язык включать функцию чтения строк?
Оба вопроса неоднозначны. Если мы программируем игрушку двумя словами, то среди команд языка совсем необязательна команда чтения строк, в игрушке может просто отсутствовать устройство для чтения текстовой информации, скажем, потому язык не должен включать в себя названия процедур, обозначающие процесс чтения строк. Это даже глупо – зачем чтение строк в коде, управляющем игрушечным зайцем – на экране ли на полу ли. А вот компилятор вполне может читать строки и, что интересно, различать разделители строк, в противном случае вся программа должна была бы быть записана в одну строку?
Настойчиво напрашивается мысль, что не бывает «минимального как такового», а бывает «минимальность тех или иных показателей».
Какой компилятор минимальнее – воспринимающий строки или невоспринимающий. Может быть минимальный компилятор – это компилятор без распознавания строк, получающий некий код и формирующий из него цепи?
Что, если команды компилятору подаются в виде каких-либо условных кодов, а не строк?
Что, если устройство программируется нажатием клавиш? (программируемый микрокалькулятор) Встроенный компилятор микрокалькулятора минимальнее, чем надстроенный, если избыточна необходимость распознавать строки?
В этом случае INTERPRET входит в минимальный состав слов форта (или «минимальный форт» ?) Ведь INTERPRET получает на вход строку! Возможны, кстати, любые извращения, совсем запутывающие понятие минимальности: скажем, можно над виртуальной машиной, кормящейся чистым кодом без разбора строк, надстроить, воспользовавшись памятью и внутренними командами, интерпретатор строк
Кстати, должен ли компилятор двухкомандной игрушки быть в состоянии добавить в конец кода обозначение конца цепочки – останов машины? Или это нарушит его минимальность? J

Видимо нужно различать
- компилятор (целевой или «местный»)
- язык
- виртуальную машину (с компилятором или без)
Всего 5 вариантов, - о минимальности чего мы говорим в данном случае?

Тем не менее, принципиально решение возможно,только в каком виде?

Если "принципиальное", то в плохом. Неудобном. Потому что "и нашим, и вашим" в ситуации, когда разные модели МК чуть ли не специально друг другу противоречат обходится себе дороже. Если в такой ситуации искать решение, которое позволит не глядя перекидывать код с одной модели на другую, то получится ну очень неэффективно. Ведь если рассмотреть процесс проектирования, то закидывание туда системного ПО - не единственный и не всегда ключевой шаг в разработке. МК может быть выбран из-за какой-то периферии, которой нет у других моделей, из-за нужного сочетания объемов памяти, корпуса и производительности, из-за аппаратной поддержки какой-то критичной для проекта операции. Во всех этих случаях разработчики не рискнут пустить дела на самотек и не проверить, как именно оно работает, и все ли в порядке. Следовательно, пустят тесты, возможно, посмотрят на скомпилированный код, проверят, что работа с периферией идет как полагается. Это ведь компьютер "уже есть, и ладно", неправильно заработавшая программа будет стерта, а компьютер и дальше будет использоваться в своем основном качестве. А ошибки с МК оборачиваются выброшенными впустую временем и деньгами, поэтому нормальный разработчик не успокоится в ситуации "взял универсальный транслятор, а он не работает, ну и ладно".

Ну почему же «иллюзия»?
Вот здесь бы и пригодилась реализация алгоритма по простой понятной математической формуле для управления указателем. Разработчик смог бы просто подставлять доступные регистры в формулу(алгоритм).Лично меня останавливает незнание всего зоопарка.

ну, вот нету готовой. (не секрет, а предмет обсуждения).


может есть, а может и нету.


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

Просто, понимаешь, можно написать систему с использованием в ~30 примитивов (взять тот же eForth), соответственно получатся тормоза, и, кстати, достаточно приличный объем лишнего кода, который может тебе никогда не понадобиться. Можно "перебрать" с количеством примитивов, но тогда будет много низкоуровневого кода, в котором легче делать ошибки, и который требует больше времени на реализацию.

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

Вот, кстати, нет. Было бы желание.

Ну и каким же образом это следует делать?

Прежде всего, это достаточно большой объём работ, т.е. первое, что следует сделать - обнаружить желание у группы людей а не у одного человека. Затем следует обобщить опыт различных "недофортов" и "модифицируемых фортов",
3.
4.
...
...
Конечный продукт будет представлять собою (можно, конечно, и подробнее) нечто среднее между оптимизатором и движком переборной игры

мндя, куда обсуждение дошло
Похоже, достигнут логический конец - надо сделать ИИ, чтобы потом ничего не делать
а ИИ должен будет отдуваться
только дудки, ИИ будет тоже хитрым, будет лениться, отлынивать, искать отговорки и мечтать о созданнии ИИ^2
в сысле, ИИ, созданном самим ИИ
кстати, у Лема в кибериаде уже был описан такой сценарий (запамятовал, как он называется)