gudleifr писал(а):
FORTH-OS: это ОС, в которой на этапе (3) не надо будет откатываться назад. Где язык команд будет достаточным для создания "машины" следующего уровня.
Т.е. достаточно иметь с своем составе компилятор исходников ЯВУ или скриптов?
Hishnik писал(а):
А такая ОС будет каким-то особенным образом управлять ресурсами системы?
Можно сделать программируемым образом. Сейчас же обычно управление ресурсами жестко встроено?
Хотя, смена ядра ОС "на лету" - тоже под это подпадает...
Но для этого нужно железо с возможностью "повторной инициализацией". А то встречались мне "однократно программируемые системы", которые требовали перезагрузку для переконфигурации. И системы на ПЛИС этим страдали.
А как сейчас,
Hishnik, уже можно переконфигурироваться на самОм софтовом проце в рантайме и без кросс-системы?
Мне вот бОльше нравится смотреть со стороны высокого уровня, со стороны пользователя.
Если система целостная и для изменения ЛЕГКО доступны все ее части(потенциально, заставлять не стОит), причем прозрачным способом, то все равно, что лежит ниже.
Может, там оптимизирующий компилятор стоит, который стековый шитый код перекомпилирует для чисто регистровой аппаратной платформы. И делает он это при необходимости - ну, пользователь указал, что если вот этот модуль выполняется более стольких-то раз или тратит более такого-то количества системного времени, то его оптимизировать - перекомпилировать внутреннее представление JIT-ом.
А если через интерфейс можно заменить файловую систему, протоколы шифрования, распределение памяти - выделить бОльше (или меньше!) файлового кэша...
А если вообще систему можно БЫСТРО откатить на пару часов назад - для отладки программ будет Рай!
В принципе, все это есть, но части очень несогласованы между собой. Происходит ЧУДОВИЩНОЕ дублирование кода.
И не только кода. Возьмем цикл сообщений. Информация проанализирована и разделена, потом она пропускается через одну точку - очередь сообщений, а затем снова разбирается по обработчикам!
Так что в ForthOS должна быть, кроме
целостности, высокая степень повторного использования кода. Заодно - компактность и не очень хорошая степень сжатия кода. Или степень сжатия хорошая, но у несжатого кода д.б. значительно выше быстродействие. "JIT" Мура в colorForth-е очень неплох для проверки идей.
Командный язык, по идее, д.б. избавлен от постоянного перечисления параметров и сложных скобочных конструкций.
Вполне возможно, что ForthOS будет состоять из нескольких DSL - для разных частей есть свое оптимальное (по каким-то параметрам) представление. Ну, собственно это такие лексиконы...
А в интерфейсе как минимум д.б. двумерный доступ (использование области экрана - GUI), а не одномерный, как командная строка. Хоть ее и раскрашивают для увеличения информативности, но это 1.5-мерность...
Продолжать?