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

ЗЫ. Кстати, gcc именно через трансляцию в Асм и работает.

Дык, это можно сделать на любом переносимом языке. Точнее в любой ОС, реализованной на требуемых машинах.
1. Ни о какой трансляции с машинно независимого здесь речь не идет - тупо переписывается (или перекомпилируется) ядро. Это как Java - чтобы писать на ней на некой машине, нужно чтобы там кто-то ее реализовал.
2. В случае непереносимой ОС (отсутствия ОС) вопрос о переносе FORTH просто не ставится т.к. потребные к написанию интерфейсы (драйвера) будут весить настолько больше самого FORTH, что написания нового ядра просто никто не заметит.
3. Самое страшное: нет никакого машинно-независимого, мета- или просто достаточно универсального стандарта "того, что у FORTH внутри".

Да, там действительно много лишнего и автор пытается сделать нативный код да еще и оптимизировать. Но в качестве отправной точки(слегка перенять опыт) пойдёт.

Автор ForthEC не поставил задачу сделать после этого "только" ForthEC на ForthEC, как поступает "самоуважающий" себя язык

Вот я то сколько пишу и никогда не знал, что при отсутствии ОС надо писать какие-то особые интерфейсы. Дёрнуть ногой это от одной до 5 асм-команд(дёргать можно по разному), USART/ADC/DAC/Timers/SPI/I²C/I²S - практически типовые интерфейсы слегка отличающиеся на разных платформах(к примеру могут быть совмещенные интерфейсы или есть/нет аппаратные FIFO), USB/CAN/Ethernet - устройство сложнее, но практически стандартизированные. Есть еще прибамбасы типа поддержки криптографии, но там так-же работа типа один вход-один выход плюс настройка. Разные адреса, разные способы доступа, разные количества, но всё практически сворачивается в стандартные 5-10 слов.

Ну давайте разберём одну из моих железяк. Внутри контроллер на 64кБ флеш-памяти с возможностью страничной её перезаписи слегка через задницу, 8кБ оперативки и немного (1кБ) энергонезависимой памяти данных с по-байтным доступом. Снаружи GSM-модуль(текстовый поток), GPS-модуль(текстовый поток), ноги, двигатели, несколько датчиков. И из отладки один UART-порт(можно прикрутить Терминал). Ни экрана, ни клавиатуры в устройстве нет, да и возможности изнутри модифицировать свой код хоть и есть, но не стоит этим увлекаться (при записи байта переписывается вся страница, а число перезаписей не безгранично). И как ты предлагаешь действовать с перекомпиляцией ядра?

И это проще написания FORTH? Килобайта этак на два (ну, четыре)?
Это не я предлагаю, а Вы. Берете этот самый e-исходник из ForthEC и перекомпилируете. Если Вы не сможете организовать на своей железяке нормальный FORTH-цикл работы, то и заморачиваться не стоит - компилируйте с "нормального" языка. FORTH все-таки жутко тормозной и память-жрущий.

Где-то пол кБ в результате на всю периферию.

Не-а. Беру а-ля ForthEC и перекомпилирую исходник скажем SPF2/3 (тех которые были еще с шитым кодом) после допиливания низкоуровневых слов.

Если Вы не заметили, там всё равно надо разбирать 2 входных текстовых потока. Плюс еще есть желание через узкий канал SMS (не более 160 символов за раз) иметь хоть какой-то скриптовый язык.

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

Того и другого и лучше без хлеба.

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

Тогда понятно, почему мы не можем договориться. Задачи-то, взаимоисключающие. Я про проигрыш в одном, вы про выигрыш в другом, и наоборот.
Возможно, что здесь нужнее не компилятор "с FORTH", а компилятор "на FORTH".

Похожая тема данной.
Помогите найти хоть бы один кросс-компилятор, что ли?

Написать на Си, выделив аппаратно-зависимые модули?

Ага... Тем и спасаюсь. Правда всё чаще начинаю вспоминать поговорку - Мыши плакали, кололись, но продолжали жрать кактус.

Да нет, Форт написать на Си и адаптировать под новый МК по мере их появления. eForth, кажется, в этом ключе написан.

Это только замена мелкой проблемы проблемой крупной.


Я понял так (поправьте, если ошибаюсь):
1. Т.к. если задача решена сама по себе, известно, на каком железе надо работать и дальнейшего допиливания не предвидится, то ни о какой проблеме речь не идет. Тупо пишем и сдаем.
2. Теперь надо решить, что составляет самую насущную проблему? В чем она состоит?
3. По Вашим словам, в железе Вы волочете, т.е. ту часть "машины задачи", которая обеспечивает "железопригодность", можете написать без проблем, на чем угодно. Т.е., если бы задача этим исчерпывалась, то никакой FORTH Вам бы не был нужен. Подключали бы к кросс-компилеру нужные библиотеки - и вперед.
4. Раз FORTH нужен, значит, задача решена не до конца. Проблема в логике? Ее надо тестировать, дорабатывать, развивать? Или, даже, эта часть еще просто "висит в воздухе"?
5. Есть разные пути решения проблемы:
5.1. Установить FORTH на железо. Раз вы разбираетесь в железе, то проблемы с его сменой с FORTH не будет. Просто добавляете к знаниям железа знание FORTH. (Например, Баранова и Нодрунова). Затем переписываете его под любое желаемое железо. (Поправить макросы в ассемблерном файле нет никакой проблемы). Следующая проблема на этом пути: работать на чистом FORTH не так много сейчас найдется охотников. Это будет просто перенос решения задачи в наименее комфортные условия. Выигрыш на этом пути: можете умыть руки после сдачи продукта и возложить решение на пользователя - пусть теперь он учит FORTH.
5.2. Предлагать решение для каждой железяки в виде готового продукта, требующего не перепрограммирования, но только настройки. Но для этого надо сначала решить задачу "до конца". Т.е. написать не только железячные драйвера, но и виртуальные. Изготовить "полную" машину, решающую задачу. Можно, правда, действовать методом последовательного приближения... Но, боюсь, FORTH здесь многим не поможет...
5.3. Попробовать решить задачу FORTH-методом на бумажке, пока забыв про железо. Т.е. начать с виртуальных драйверов. На этом пути можно будет решить какого вида FORTH нам нужен. Может, у него будет не один входной поток, а три. Может, несколько стеков, может, это будут пара FORTH с общей "кормушкой"... Может, это будет Smalltalk, или FORTH сократится до нуля, оставив набор взаимодействующих блоков настолько Вам понятный, что Вы его на программаторе для любого железа будете легко ваять.
5.4. Поставить FORTH на большую машину. Зачем?