В своё время я принимал участие в написании большой Форт системы. Ядро (хард слова) были написаны на TurboPascal-6.0. Распределение памяти, работа с устройствами и файлами - DOS через ТР. Все внешние библиотеки на Форте, в том числе работа с DBF. Всё это называлось "MiM" система. Работала на 286 персоналке с 2M памяти, тянула 18 терминалов CM-7209, если память не изменяет (2 com порта на самой персоналке + 2 дополнительные платы по 8 com портов). Ввод/вывод реализован через прерывания. Сама система многозадачная.

Так вот самая большая сложность в реализации, это переход на следующий уровень абстракции и скрытие деталей предыдущего уровня. Уровня словарей не достаточно. Происходит как бы разрыв между данными и кодами. Сейчас, я сказал бы, что нужно вводить ООП сразу в форт, что бы легко можно уйти от слишком "мелких" понятий. Можно сказать словами gudleifr - несколько интерпретаторов (задач) работающих на "основе" нижнего слоя (форта). Но мне не удалось (вернее в погоней за скоростью пришлось отказаться) полностью закрыть верхним интерпретаторам (задачам) доступ в ядро. Постоянно приходилось в качестве оптимизации включать в высокоуровневые слова мелкие hard слова. В конечном итоге, это сильно усложнило программирование. Мой собственный вывод: чистый форт эффективен только в небольших задачах. Большие системы на нём писать сложно, именно из за отсутствия встроенных механизмов инкапсуляции. Если поверх форта реализовать высокоуровневые механизмы, то он не будет отличатся от большинства обычных интерпретаторов, например Python.

Все же перевод на Форт из соображений получения какой-то смутной выгоды вряд ли может рассматриваться как целесообразный. Опять же, выбор архитектуры - это прерогатива программиста, и создать инструмент автоматизации пересмотра архитектуры будет очень сложно уже в части формализации такой задачи. Даже диагностику или какое-то профилирование кода на Си... как? Что именно искать в коде, чтобы заменить эффективным Фортом? Например, эквивалентом какого заменяемого кода на Си могла бы стать иерархия словарей с динамическим изменением контекста? Мощное решение, убирающее множество вопросов, которые иначе пришлось бы решать в compile-time. А в Си пришлось бы именно предусматривать массу вариантов в коде,... или же писать Форт-машину.

Просто, навязывать FORTH способы Си-инкапсуляции не стоит.
Речь не целесообразности. Просто, часто возникает задача анализа ПО. Здесь важно не то, что будет написана "программа, делающая тоже самое", сколько то, что в удобной (машинной) форме будет записано "что она делает вообще".
Элементарно. Вы сначала решаете, чего хотите этим способом добиться. Затем - честно реализуете на C. Например, перекомпиляцией, таблицами указателей на функции, подгрузкой динамических библиотек... Или еще как... Но, скорее всего, речь будет идти о паре if-ов или #ifdef-ов...
Впрочем, к делу это не относится...

Следовательно, речь идет или о прототипе, или о системной модели. Вполне в духе Форта, но это не вполне переписывание программы с Си на Форт.

Ну уж нет. Сначала решают, чего нужно добиться, а уже потом подбирают способ. Изучениев возможностей языка/способа - отдельная задача поискового класса, но не инструмент для выполнения конкретного ТЗ. Мне интересны как раз те соображения, которые могли бы вызвать переписывание состоявшегося продукта с помощью Форта.

Вряд ли возможности Форта по интерпретации и компиляции на лету полностью перекрываются "регулярной" программой на Си. Если развивать процитированное, легко придти к идее форт-машины на Си

<вычеркнул, т.к. это все оффтоп - и про "прототипы", и про "контексты"...>

Любого с ООП.

По поводу перевода на Форт. Ок, перевели. А в Си-шном исходнике автор ошибку исправил. И что теперь делать?
- переводить заново и заменять все
- искать эквивалентные места и исправлять
- перевести и попытаться объединить
И еще. В IDE ОС должны быть средства поддержки анализа, как минимум, Си-программ и рефакторинга! Причем с поддержкой тегированного протокола работы(отметки мест и их смысла, объединения нескольких мест и их эквивалентов в Форт-аналоге.

Если использовать редактор "поумнее", знающий о лексиконах и словарях(имеющий метаинформацию), то выходящая из такого редактора программа уже будет чуть проще, чем традиционная, обрабатывающая сложности и ошибки(которые можно исправить еще при редактировании) во время компиляции или в рантайме.
И мне хочется такой редактор как составную часть ОС! Т.е. документация ОС должна быть встроена в редактор! Ну или удобно доступна из него.

И, похоже, лучше будет хранить только внутреннее представление программы, даже не исходник(!), генерируя нужный код при необходимости и с нужными оптимизациями. Хгм.... От Форта остается только язык проектирования... Ну и реализации некоторых частей, для которых нет лучшего эквивалента(программа на colorForth == конечные автоматы == регулярные выражения), или предпочтение Форта автором фрагмента. Значит, целевой сегмент ОС по основным возможностям - исследования/оптимизация алгоритма, а по размерам и открытости исходников - гиковские, встраиваемые и военные системы.

Чем больше Вас слушаю, те более недоумеваю: зачем Вам FORTH? IDE, безопасный код, ООП... Как бы, с точки зрения FORTH (т.е. конструирования проблемно-ориентированного языка) это просто детские болезни...

ООП будет работать до первого EVALUATE. В Си нет возможности реализовать его "статическим кодом".

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

Я ценю Вашу эрудицию, но по-моему, Вы опять ошиблись темой. Здесь - не про "ОС дся ПК" и даже не про "ОС вообще"... а про "некоторые свойста ОС"...

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

Топикстартер:
Далее по тексту.

Форт на PC - практически любая ОС запускает приложение на Форте. ДОС, Windows, *nix - неважно. Смысл заменять еще и сервисы этой ОС ну разве что спортивно-пропагандистский.
Форт на МК - см. предыдущий пост. А чем таким у МК надо управлять, что нужна ОС?
Форт-процессор - еще проще, чем МК. Прослойка между словами Форта и машинным кодом не требуется.
В случаях МК и Форт-процессора остается вопрос с драйверами, но он есть всегда. Требования к драйверам формируют сами устройства, а ОС и прикладная программа вынуждены маневрировать в оставшемся пространстве. Если устройство формирует запрос на прерывание, то это запрос на прерывание. Оно так устроено, и это не обсуждается. Поэтому работа над драйвером на 90+% состоит из изучения последовательностей чтения/записи в ВВ и отображенные на память регистры, обработки прерываний и т.п.

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

Ну, мы же Си-код заменяем на что-то получше - Форт! И тут, естественно, у нас больше возможностей!

И хочется его иметь тоже гибким, как и все остальное! Чтоб система не вываливала на каждый чих пользователя несколько экранов сообщений(реальный пример, смотрел в procmon в Windows), а делала только то, что нужно пользователю.
Ну, меня интересует максимально простая и гибкая архитектура, чтоб можно было реализовать некоторые эффекты взаимодействия прикладных программ... И чтоб это была цельная система, а не сборка кусочков разных технологий. Ну, или хотя бы не очень разветвленное дерево технологий. Меня не устраивает, что для установки простой программы я должен откомпилировать компилятор экзотического языка, который будет интерпретировать код, генерирующий программу, которая захочет библиотек на 100Мб и к которой еще надо будет поискать документацию, где описаны ее параметры(как в Linux. Может, чуть преувеличил).

Внезапно, в соседней теме:

Не будем рассматривать вопрос реальной потребности в такой реализации.
Допустим: "патамучта нада!"
Конечно, ввиду того, что это "далеко не ОС", реализация, очевидно, будет по варианту (1), но для примера сойдет.

На что это похоже (совсем из другой игры)?

Т.е. опять - интерпретатор.
Насколько он похож на интерпретатор FORTH?
Данные:
ПОТОК - с одной стороны проще (вместо слов - почти одни литеры, редко числа), с другой сложнее (набор команд зависит от состояния).
ЗНАЧЕНИЕ - здесь, скорее всего, не только команда но и значения всех текущих переменных (множество жетонов, маркеров, позиция на поле, записи).
СТЕК - команды с параметрами есть, значит, он нужен. С другой стороны, т.к. в алгоритме есть возможность отката вычислений, то стек нужен еще раз.
СЛОВАРЬ - в рассматриваемой книге-игре, очевидно словарем будут наборы команд и параграфов, хотя, конечно нужны и более простые "чисто игровые" слова (кубик, выбор, схватка...).
Процедуры:
ОК - выдача не только самого "Ok", но и текста параграфа. И, самое главное, подстройка под состояние набора допустимых команд.
СИМВОЛ - По условным составляющим: EXPECT - можно допустить разные варианты для разных состояний (просто команда, команда с числом, выбор варианта...); WORD - рудиментарен (все делает EXPECT); FIND - самое важное для него проверка допустимости команд (делать словари для каждого отдельного состояния, наверное, геморройно, скорее - матрица допустимости); NUMBER - тоже рудиментарный (часть EXPECT?).
ВЫПОЛНИТЬ - в смысле текущий параграф СЛОВАРЯ с введенным ЗНАЧЕНИЕМ, что бы это ни значило...
КОМПИЛИРОВАТЬ - отсутствует, разве что пытаться хранить в СЛОВАРЕ, а не в ЗНАЧЕНИИ текущее состояние.
СЛЕДУЮЩИЙ - настраиваемое, в зависимости от цикла, переход либо к следующему параграфу, либо к текущей точке возврата...

А теперь представим, что подходящего FORTH у программиста пока нет. И если его писать с нуля, не имеет ли смысл включить некоторые из перечисленных механизмов в параллель его внутренним структурам сразу, чтобы потом не реализовывать их "поверх"?