На нижеследующих страницах располагается обрывочное и не упорядоченное описание некоторой модели программирования. Говоря по старому - операционной системы. Мне не очень нравится это слово - оно тянет за собой ворох древних ассоциаций, сущностей, которые уже не нужны, приёмов, которые уже неприменимы.
Читая это, прошу Вас, постарайтесь отвлечься от привычного. От адресной арифметики (это легко), от понятия "файл" (это сложно), от понятия "оперативная память" (кому это вообще по силам:)... То, что описано ниже необычно. Очень необычно. К нему нельзя подходить с привычными мерками. Если у вас возникает вопрос "где тут описание API", то вы уже промазали. Его нет. В принципе. Есть нечто похожее, но это очень несущественная часть идеи. Нет файлов, нет понятия "программа" и "процесс", нет языка Си. Есть, правда, ассемблер, но если вы привыкли писать на ассемблере, то здешнй вас не порадует, а повергнет в ужас. От почти что всего привычного нужно отвлечься.
Отвлечься надо и от вопросов эффективности. Описанное здесь не преследует цели достичь максимума эффективности. Преследуется цель создать концептуально новую среду, удобную для написания сложных, гибких, удобных и надёжных программ. Удобную для меня, чтобы сразу отвести возможные возражения. :-) Об эффективности тут тоже думается, но только не в ущерб красоте идеи. В конце концов, это же хрустальный замок (слово "дерьмо" ниже относится не к замку, а к описанию:), а не бизнес-план.
Просьба. Если вам кажется, что для укладывания в голове написанного ниже нужно менее трёх полных прочтений то... короче, прочитайте ещё пару раз, если не очень сложно. :-)
Концепции, сплавленные здесь, отчасти рождены коллективом программистов (Завалишин, Никонов, Положинцев) в 1990-м году, отчасти придуманы мной за последующие десять лет, отчасти взяты из гениального творения Intel по имени i432, отчасти - из таких разработок, как ОС Spring, Graal и Plan 9, OS/2 SOM/DSOM и OS/400. Концепция в целом или отдельные идеи обсуждались со многими людьми, всех уж не упомню, вероятно. Но, тем не менее, хочу сказать спасибо за идеи или критику С. Вакуленко, В. Антонову, А. Аристову, А. Рощину, А. Селькову и П. Квитеку. Кого забыл - извините.
Ещё раз оговариваюсь - это не спецификации системы. Это - аморфная куча идей, которые умозорительно хорошо ложатся вместе. Я буду очень рад услышать любую конструктивную критику, предложения и дополнения. Если вы чувствуете себя достаточно заинтересованным, чтобы попытаться довести всё это дерьмо до более формального вида, а то и написать пару хедеров, или, к примеру, сделать БНФ-схему - я только за. Если захочется просто потрепаться на тему - you're welcome too. Пишите, звоните, приходите на чай.
Итак. Нет, я просто крайне неформально напишу, что вспомню, не более того. :-) Да. Для определённости рабочим названием проекта будет phantom или фантом. Просто чтобы было удобно ссылаться.
NB. Для обсуждения описанного здесь создан форум. Обсуждение в нём преследует практические цели. То есть создание законченной спецификации Фантома и реализацию его или, по меньшей мере, его компонент. Речь не идёт о месяце или двух - я был бы рад получить что-то как-то работающее через полгодика, к примеру. И проблема тут не с написанием, а с дизайном.
Вариант методики отслеживания рестартов
Первая версия описания устройства подсистемы VM
Система с точки зрения разработчика системы делится на две части. Подземелье и надземелье. С точки зрения программиста, который пишет под эту систему существует только надземелье. Подземелье представлено в нём своим агентом-аватаром :-) - объектом, методы класса которого реализованы "нечестно" - отличным от любых других объектов образом. А именно - кодом, спрятанным в подземелье. Кроме того, "подземным" образом реализованы и методы некоторых других классов (например, классов "целое число" или "строка") - все эти классы предопределены и существуют всегда.
Всё, что над землёй - объекты. Всё, что не объекты - под землёй, и его очень мало. С точки зрения современной идеологии "подземелье" - это ядро, а точнее - микроядро. Код ядра не подвержен пейджингу вообще. Его там мало, 90% ядра всё равно пейджить нельзя - нет смысла заморачиваться.
Исполняемый код над землёй - интерпретируемый (или прямо исполняемый на специальных архитектурах процессоров), чисто объектный, причём аналогов статическим методам (как в С++) и глобальным функциям не существует. Причина проста - глобальное пространство имён отсутствует в принципе - чтобы не создавать почвы для конфликтов. Есть лишь глобальное пространство имён типов. Оно иерархично и строится по принципу дерева доменов. Каждому разработчику - по ветке, а уникальность внутри ветки - его забота. У объектов бывают public и private методы, остальные члены бывают лишь private и, возможно, protected. Все указатели - парные (адрес объекта/метода и адрес объекта-класса), credits - Сергею Вакуленко. Класс есть объект класса class. class::code.имя_метода имеет тип language.code.executable.interpreted и содержит код метода.
Исполняемый код под землёй - платформо-зависимый. Исходно, по всей видимости, должен быть написан на Си, возможно - с ассемблерными вставками. Не принципиально, впрочем.
Аналогом "программы" в традиционных ОС в Фантоме служит класс (тип). Если он имеет выделенный метод main, то при создании экземпляра (объекта) этого класса создаётся новая нить (thread), исполняющая код метода main. Окончание работы этой нити не является специальным событием.
Отметим отдельно, что в Фантоме объектом является целая переменная, строка, программа, драйвер - всё от мала до велика.
В системе нет понятия "диск" и "память". Существует глобальное для компьютера адресное пространство, прямо адресуемое как оперативная память, но хранимое, как дисковая память. То есть вся память виртуальна, вся память всегда (ну, почти всегда:) имеет актуальную копию на диске, вся память адресуема единообразно, видимых для программиста операций дискового ввода-вывода не сущствует. Все объекты живут всегда. (То есть умирают лишь по желанию программиста или по отсутствию ссылок извне и нити в контексте.) Понятия shut down и reboot нет - есть понятие "уснуть" и "проснуться", есть понятие "упасть" - в случае падения системы работа возобновляется с контрольной точки. Это - очень тяжёлый и муторный момент. Описан отдельно. См. также подсистему виртуалной памяти.
Эксепшны.
Нормального русского слова не знаю. Обломы? Возможно. :-)
Вся система строится на них в том смысле, что никаких return -1, никаких if( (c=getchar()) == EOF), никаких errno - в помойку, всё это в помойку. Да и getchar и вообще поллинг в неё же, но это - отдельная история.
Все вызовы методов могут вернуться нормально, а могут вызвать exception. Все стандартные методы сообщают о неудаче исключительно через exception. Возврат выделенного значения для обозначения неудачи - крайне плохой тон в фантоме. Крайне.
Больше на эту тему можно прочесть в моей старой статье об exceptions. Думаю, это ещё вполне актуально и вполне иллюстрирует стиль, который я бы хотел видеть базовым в Фантоме.
Реентерабельность
Обеспечивается "вручную". Никакой объект не гарантирован от повторного входа в тот же или иной метод. Оградить себя от беды - его забота. Возможно, это неправильно и нужно ввести гарантированную системой защиту.
Кстати, может быть кому-то покажется любопытной концепция ленивых нитей. Она была придумана и сразу отброшена пару лет тому назад, но всё равно любопытна и, может быть, где-то ещё сослужит.
Код.
Здесь. Возможный "штатный" язык (не готово даже на 30%). Имеет смысл прочесть описание проекта языка Classic Сергея Вакуленко - из него, мне кажется, много, что имеет смысл позаимствовать.
Сеть.
Может быть, очень может быть, тут есть смысл привинтить corba и забыть про всё остальное, как про страшный сон. Это будет означать, что нужно забыть и про всю окружающую нас (осторожно - эпатаж) необъектную помойку из древних ОС и протоколов (хорошая опечатка - простокол), но тут даже моего авангардизма мало. Я полагаю, что, как минимум, реализация TCP/IP необходима - это для связи с legacy OS. И это, собственно, не проблема - ясно, как сделать, ясно, как использовать.
Вопрос - как реализовать сеть для взаимодействия между собой фантомов. Пока ответ - corba. Не уверен в его правильности.
Драйверы.
Драйвер - это просто объект (какого-то класса, вероятно, унаследованного от класса system.driver?), обладающий доступом к железу и способный вешать метод на прерывание. Вероятно, тут уместна схема реакции на прерывания, аналогичная Windows NT - когда в контексте собственно прерывания отрабатывает минимум кода, а остальное (DPC) "дорабатывает" потом, как только представится уместный случай. Я не уверен в том, что отработка прерывания интерпретируемым кодом - это так уж здорово. Возможно, что все драйвера будут реализованы в "родном" коде процессора. Или часть их. Например, драйвер клавиатуры может и не торопиться. Короче, это вопрос лишь эффективности и с концептуальной точки зрения его фиксировать не обязательно. Выбор варианта оставляем на совести автора драйвера.