Собственно, вот такая тема. Задача - для набора платформ Arduino/ARM/.. иметь возможность подключить один модуль в виде #include "forth.h", и добавить к форт-машине функции основного проекта (по умолчанию void(), которые могут работать со стеком функциями Push/Pop).

Нет, xxxforth не подойдет при любом xxx. Задача не в том, чтобы заменить весь софт на Форт, а чтобы к существующему софту организовать интерпретатор и JIT-компилятор с целью сокращения времени на итерацию разработки.

Не вижу противоречий и для использования xxxforth на С/С++ для обозначенной в постановке задачи.

P.S. Ну, разве что, можно подумать как и какой "прикрутитить" JIT-компилятор при этом. (а может. AOT)

Я вижу принципиальные противоречия, которые потом обязательно проявятся. Программное обеспечение сначала проектируется, и у него есть своя архитектура, правила взаимодействия между частями и приоритеты по характеристикам. Вопрос не в том, чтобы скорее-скорее показать использование Форта, а чтобы "играть в долгую" и сделать решение, которое встраивается как компонент в целый класс проектов. Тут и проекты как раз подъехали, интерпретатор там нужен, но в составе ПО, которое там неизбежно будет. Говорить "а давайте вот это все выкинем и перепишем" - зачем? Оно работает. Command Line Interface и скрипты, где слова Форта - обертки над готовыми функциями - да, надо. Какой xxxforth на такое способен - это дольше выяснять, чем написать требуемое.

Эээ... так вроде у вас же это и было где-то

Да, уже не первый раз такое вылезает. Надо уже добить. Хочется, чтобы оно без лишних настроек подключалось к проекту через единственный include, а дальше можно было бы оформить обертки над функциями проекта чем-то вроде AddWord("Nameifword", addrofvoidfunction).

У меня была идея сделать некий консольный интерфейс для вызова СИшных функций на микроконтроллерах с околонулевой необходимостью к портированию с возможностью к построению скриптов. Получился Forth.
Нюансы:

В целом, реализация железонезависимая, однако форма хранения системных слов требует одного адресного пространства => контроллеры с гарвардской архитектурой (avr, pic) не поддерживаются

Подключается два .с и два .h файла минимум

Реализация железозависимых функций предлагается к реализации в отдельных словарях, которые подключаются динамически (однако, функции по прежнему могут лежать во flash. Нужно только 1 переходное слово в ram)

Слова можно добавлять и динамически через функцию forth_add_function(). Из Сишной функции можно делать все, что угодно, т.к. в нее передается указатель на vm. Флаг немедленного исполнения также будет работать.

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

nostdlib

библиотека занимает примерно 10кб flash (arm-none-eabi, -Os). Глобальных переменных нет, forth_t = примерно 100 байт. Остальное (размер стеков, памяти) решает юзер

Есть тесты, примеры (под Linux)

Проект активно развивается, т.ч. многие решения пересматриваются, API плавает

Ссылка: Codeberg Github