Собственно, вот такая тема. Задача - для набора платформ 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

Интересно. А оно для каких плат предполагается? Если одно адресное пространство, то это что-то на уровне 64+ кб памяти и ARM, RISC-V и прочее.

Единое адресное пространство характерно для arm, risc-v, x86, x86_64, pic32*, stm8*, msp430*, Xtensa. С теми, что со звездочкой, не работал, но по идее должно скомпилиться. По сути, только AVR и pic8 из популярных являются чисто гарвардскими, т.е. с разделенной памятью.

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

Я тут вижу два интересных момента (пока).
1. Управление объектами и выделение памяти.
Для МК это чуть более опасно, чем для ПК, потому что динамическое создание потоков Форта может загнать систему в критическую ошибку. Тут выбор между только compile-time с простой параметризацией (сколько потоков и кому что дать), либо допускать динамическое создание потоков, что выглядит гибче и технически возможно. А вот соотношение рисков и возможностей - интересно...
2. Ограничения по словам.
Чтобы движок не застревал внутри слов, они не должны иметь циклов с проверкой условия выхода. Обрыв внешнего сигнала - и один поток остановил все. Или таймаут на каждом таком слове, или в принципе выносить проверки в примитивы и делать циклы только на уровне Форта. Тогда будет регулярная передача управления.

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

Смотря, какие задачи стоят перед внедрением языка Форт в проект.

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

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



Мне видится потенциал такого решения в динамической подгрузке скриптов по сети или с внешней карты памяти. Раскатывания сишной программы, скомпилированной с -fPIC, по ОЗУ требует места для всей такой программы сразу, а размещение в одной области разных таких программ (т.н. оверлеи) требует постоянного считывания из постоянной памяти, что часто очень медленно. Со скриптовым языком мы можем считывать текст скрипта построчно, что и место в ОЗУ экономит, и на времени считывания из медленной памяти выигрывает.

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