А если делать модельную файловую систему Форта внутри (одного большого) файла, как это обычно делают виртуальные компы? Ошибки можно половить... Хотя, конечно, исчерпывающего тестирования не будет
А так ли надо работать с чужими файловыми системами? Вон ColorForth, вроде, без них обходится. От задач зависит.
И кто сказал, что традиционные файловые системы(ФаС) хорошо подойтут нам? М. вообще сделать ФаС как базу данных с несколькими индексами. А физически хоть в одном файле, хоть распределенную... IMHO, работать будет удобнее!
Кстати, современные ФаС не такие и сложные. Вон, FAT16 прошивают в микроконтроллерах! На Форте тоже реализации большими не будут. Единственно, надо проверять крайние случаи. Ну, или описывать ограничения в документации. А лучше сделать несколько решений - как минимум 3 - простое(легко понимаемое и легко переносимое), быстрое(оптимизированное для типичной конфигурации) и правильное(полное, с возможностью расширения до пределов оборудования).

Коллеги хотят , чтобы ФортОС запускалась ппараллельно с другими ОС с одного винчестера (менеджер загрузки и т.п.) Логично, т.к. может понадобиться всё - сразу полностью перейти на новую ОС трудно.
Вопрос: зачем маленький упомянутый Линукс (помещается на специально отформат-ю дискету) имеет столько менеджеров файловых систем?

Здесь сразу принципиальный вопрос: ошибки оно само находит и исправляет, или надо будет вытаскивать носитель и подключать к "правильному" PC?

А 3 решения - надежный залог последующего хаоса...

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

Нет, если для основ использовать надежные, проверенные и документированные исходники. И свои расширения сопровождать хоть минимальной документацией...

Остается, например, момент "в процессе заливки обратно отключили питание". Это все не так просто.


Тогда проще взять MS-DOS. Или готовый аппаратный сервер накопителя (хоть бы и в виде одноплатной ЭВМ). Иначе получается "непонятно, зачем, но перепишем все на Форте". Еще немного усилий по оптимизации, и итоговый код будет максимально приближен к своему промышленному аналогу.... но какой ценой!

Можно, но надежность будет на уровне MS-DOS... и размеры тоже...

IMHO, переписывание на Форте уменьшит размер кода и увеличит возможности повторного использования кода...

Оптимизировать код должен оптимизатор. Встроенный в кодогенератор, как в ColorForth или внешний(отдельным проходом, после кодогенерации), как в SPF...
А оптимизировать алгоритм нужно для любого языка, Форт это или не Форт!
Можно еще сделать конвертор из С или сразу компилятор С и перекомпилить исходники Линукса или FreeBSD, не знаю, какие лучше. Но это если надо быстро перенести и как-нибудь.
При переработке явно обнаружится несколько мест, которые можно сделать получше... Лично мне таак кааатся(с)!
И, по-моему, сложность переписывания сильно преувеличена! Особенно, если учитывать используемый инструмент - Форт Почему я этого не делаю сейчас? - А я работаю над IDE для Форта. Пока на уровне идей, но идеи многообещающие. А инструменталкой для него будет SPF(тестовые части уже работают), а потом и CLCF.

А что плохого с надежностью MS-DOS? Работала десятилетия, и не слышал, чтобы были массовые сбои файловых систем из-за несовершенства ПО.

Его достаточно обернуть в форт-слова. Зачем повторно использовать низкоуровневые алгоритмы? Так больше шансов запортить что-то на диске. Открыть файл, закрыть файл, записать, прочитать, удалить, переместить указатель. Создать-удалить каталог. Диагностировать ошибки и выбрать правильную копию FAT. Что еще? И все это должно быть скрыто как можно тщательнее.

Да зачем? Тогда уж сразу Линукс ставим, он же есть и готов. Проще встроить форт-машину в программу под Линукс, чем ВЕСЬ Линукс пропускать через Форт-транслятор. А главное, итог-то какой? Все равно тот же Линукс и получим

Да у переписывания сложность близка к нулю. Сиди и переписывай ) А вот потом с запуском и отладкой переписанного, а особенно с тестированием вроде бы заработавшего кода - ого-го. Я так понимаю, что рабочего списка проверяемых ситуаций пока нет?

На Форте Уже где-то было, Пишут же на асме ОС колибри и не жалуются:)

Для упрощения. Возможность действовать исходя из понимания всей системы
дает огромные преимущества.



Смотря для кого. Еще можно использовать отлаженные наработки.




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



Тоже работа

Все и сразу переписывать не надо.
После http://fforum.winglion.ru/viewtopic.php ... ight=#6385
тедо системы остается таким как есть (за исключением отведения места
под кодофайл форта). Далее можно Фортом странслировать листинги, и
получить то-же модуль. Далее, по мере необходимости, менять
содержимное листингов на фортовые определения.



Просто должны работать ряд подобранных приложений.

Там Много. Нет, там МНОГО всего... Можно откусить кусочек от понимания вопроса "сетевые протоколы", но реализовать их снизу, от MAC до приложения - не до жиру. С диском аналогично - нужно просто очень много времени потратить на проработку алгоритмов поддержки файловой системы. Хоть на чем. Форт будет потом-потом-потом. А пока вот этого понимания нет, бессмысленно вести разговор о том, что рабочий код обязан быть получен путем трансляции форт-исходников.

Ну и где они?

Что такое "все функции"? Дернуть головкой винчестера? В MS-DOS очень резво отказались от File Control Block в пользу file handler, несмотря на то, что первый метод обеспечивал широкие возможности доступа. И даже не "несмотря на", а "потому, что". Критичные к действиям прикладного программиста операции должны быть скрыты. В силовой электронике прямой доступ к функциям и потенциальная возможность устроить закоротку рано или поздно к такой закоротке приведут. Проверено С файловой системой будем иметь периодические падения от того, что программист Вася прочитал весь богатый список функций, решил, что это для того, чтобы умный человек мог их оптимизировать, и разумеется, счел себя умным человеком...

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

Гм... Классическая ситуация: не работает. И где искать?

Массовых не было. Единичные наблюдал. Но ты прав, достаточно надежна.
Больше всего не нравится странная логика в наборе ф-ций и большое количество анализов параметров. Хочется обойтись без CASE в анализе параметров.

Чтоб увеличить факторизацию и уменьшить объем кода!
А, м.б. из низкоуровневых ф-ций высокоуровневые алгоритмы использовать, сортировку, например.

Программирование на незащищенном Форте - всегда риск запортить систему!
А лучшее средство - отлаживаться в отдельной среде.

А если для проца нет С, а есть только Форт (и/или асм)?
Как простое "быстрое" прототипное решение - и Линукс сойдет! Просто громоздкий.

нет, конечно! Просто хочется улучшить качество кода. Применить подходы Броуди - их же С-шники не все знают! Для меня это задача "на позже"... Да и Мур хвалился - я почти всегда перепишу С-код и результат будет намного меньше, быстрее и лучше... Вот, хочется натренироваться так делать... Уже есть некоторые успехи, но медленно, медленно...

Handle-ориентированный доступ к файлам вполне удобен. И кстати, повторен в ANS-94

А без разницы, что есть. Главное, есть ли специалист по файловым системам, а на каком языке написать - дело десятое.

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

Дело наживное. Отлаживаться можно с помощью эмилятора
http://bochs.sourceforge.net/



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



Сейчас что по другому?
Можно для любого приложения дать доступ чтение/исполнение
к области расположения Форта в ядре системы, да и ко всему
ядру в целом. Это приведет к использованию единого набора
функций общего назначения ядром системы и всеми приложениями.



Изменения вносятся постепенно и промежуточные версии сохраняются.
Если промежуточные версии не сохранились, можно производить
постепенное превращение изначальной версии в данную с периодическим
тестированием.

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

Все равно я не вижу конкретных алгоритмов или утилит для работы с оборудованием, написанных на Форте. Пока есть декларации.