Она чуть менее, чем идеальная.

Ээээ....

Для встраиваемых девайсов (телефоны, КПК, коммуникаторы, SoC-системы), короче там где фиксированный набор железа, и тип его известен, как и принцип работы и протоколы железяк.

8-16-32-64 бит (ширина ячейки данных настраивается), остальное мона содрать с никсов.

Ээээ... ну допустим, модульное ядро, ибо на скорость пока претендовать не стоит. Вообще можно на Minix глянуть, идейки скопипастить.

Зависит от железяки, на которой ось будет крутиться, наверное.

Примерно как в никсах, академическая модель.

опять хм...

Обязательно будет. Хотя я оптимист

Можно пример ОС, где бы ширина данных настраивалась в таких пределах?

Я не о переключении ширины данных в рантайме, а о возможности компиляции самой ОС под разнобитные железяки. Ну с 8 бит я наверное погорячился.
Примеров не знаю, ибо форт никуда пока не встраивали. Хотя может и есть какая то ось которая компилируется на C в 16, 32, 64 бит... Но что мешает быть первыми, раз сейчас проектируется и обсуждается пока только концепция?

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

Глянуть надо обязательно - хотя бы на это:
http://www.minix3.ru/articles/minix3_vpechatlen.html
Жуть, да? Так вот, просьба всем еще раз подумать: "Мы будем снимать кино? Или мы не будем снимать кино?" В смысле - занимаемся ОС или комменты на форум лениво пописываем?

И вааще, как насчет первым шагом поставить ребром на голосование единственный вопрос: Делаем ось? ("Да"/"Нет")

А если самоубийц(т.е. участников проекта) наберется достаточно,- плииз, идем дальше - "всеобщее политсобрание на IRC-канале".

Скажите, пожалуйтса,
поначалу надо бы определиться где будет исользоваться ФОРТОС и что кокретно она должна контролировать.
-- засовывать драйвер NTFS - это глупо, проще прослойку вставить.
Далее наверно решиться будет ли параллельное выполнение команд, ну и видимо механизмы что называют синхронизацией.
Еще конечно про ОСРВ - гарантированное время реакции на обработку запроса прерывания.
-- Тут вот QNX помянули, а ведь заводы требуют спецов АСУТП в коих датчиков до бесконечности. еще есть SCADA.
-- под QNX разработано много программ и куча доки. я в руках держал 6.2.1 - неплохая вещь.
Какие задачи решает ОС: распределение памяти, контроль за выполнением задач (для ОС это все подпрограммы), реакция на ошибки, обработка прерываний, хранение информации (скорее не относится к ОС, а относится к тому как некоторая подпрограмма позволяет организовать данные где-то). где-то я уже это видел (ОС-9?).
А в чем преимущество ФОРТОС не ужто кто-то посягнул написать УНИХ на ФОРТ вместо С?

Хм. Речь опять пошла о копировании продвинутых (относительно) осей ...
Забыли о том, что проект может получиться только как исследовательский.

С чего начать исследовательский проект? С того, что интересно делать, а не с того, чем хорошо бы пользоваться.

А это, кстати, м.б. удобно для драйверов. Компактная программа, ей не нужна широкая адресная шина. Да и порты 8-16 разрядные (у старых/слабых компов)...

Пока мне не понятно, где её применять. Даже если это исследовательский проект, считаю, что отдача, какая-никакая, а должна быть. Писать "в стол", зная что пишешь "в стол" мне несколько сложновато.

И вообще, если писать ФортОС на Форте, то, по-хорошему, надо писать её для железяки с Форт-процессором внутри, легкую, размером с КПК, и минимальной периферией наружу (COM, LCD-дисплейчик, USB, разъем для флеш-карт, сеть и что-нибуть еще (это перечисление навскидку)), раз уж это исследовательский проект. ПЛИС-железяку брать из стартер-кита (давно хочу такое пощупать, но теперь уже только после переезда). Чтобы не просто написать ФортОС и восторгаться, что она таки написана (а толку то), а пощупать ее в железе, постоянно пользоваться ею, носить с собой и показывать другим. Вот тогда от этого будет толк.

Не хочу показаться всем еретиком, но ИМХО сейчас ФортОС писать еще рановато. Пока не вижу предпосылок для этого.

прочитал в Сценарии: высокоуровневое программирование для XXI века:А Форт бестиповый изначально. Вот и его преимущество! Улучшенное повторное использование кода. А если средство разработки Форт-системы предупреждает о возможных конфликтах... Ну или не дает простым способом сделать заведомые ошибки...

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

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

Для каждой задачи есть свое оборудование. В самом деле, не будете же вы разрабатывать драйвера для десктопной ОС или проектировать большую БД на КПК? Нужно иметь под рукой несколько документов в нескольких разных "стандарных" форматах и возможность проверить решение. Возможность видеть больше, всю картину. Работать с маленьким экраном для этой задачи неудобно, как и вводить большие количества текста. А вот простые вещи - что-то изменить в алгоритме, попробовать организовать связи по-другому - это можно и на КПК. И универсальная система разработки позволит работать и на десктопе, и на КПК почти одинаково удобно. И сделает код, оптимизированный для разных задач. Просто надо внести в нее соответствующие фрагменты кода. И эту работу в хорошей системе сделать несложно.
Форт - контекстно-зависимый язык. Уже сейчас один и тот же (правильно написанный) исходник можно откомпилировать под разные системы, как по разрядности CELL так и по разновидности ШК. Т.о. задача удовлетворительной целевой компиляции для разных систем имеет решение.

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

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

Это и будет "новый" Форт!

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

Угу, я на десктопе обитаю, ну изредка на КПК.
Т.е. не предусматривается вывод такой ОС в "массы"? Только использование в ускоспециализированных эмбеддерских задачах? Тогда я - пас.
Но посматривать за обсуждением буду.

Только что выше сказано о повторной используемости (читай - переносимости) кода форта!

Просто я почитал chess'а, и понял так, что ФортОС склонна позиционироваться, как система в первую очередь для эмбеддеров, но не для прикладного сегмента рынка.
"Повторноиспользуемость" - слово хорошее. Но БольшогоНапильника(ТМ) оно не отменяет.
Ну да ладно, может я где то и не прав. Будем посмотреть.

хм, если учесть, что не более 5% (+\- 3%, не помню точно) выпекаемых во всем мире чипов используются в буках и десктопах, а остальные, как тараканы, лезут во все щели, фраза об узкоспециальности эмбеддерских задач приобретает несколько спорный характер...