OSDev

Это уже другой вопрос.

Мне кажется, что вопросы стыковки закрытого и открытого кода решаются путём лицензирования отдельных компонентов/библиотек так называемой уменьшенной лицензией (Lesser GPL).

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

Перечитывал на ночь пейджер и много думал))
Мой прогноз оказался неточным чему я очень рад: osdev не сгинул в лету а сместился во всякий iot и прочие одноплатники. Правда он там довольно ограниченный, но это точно лучше чем ничего. И главное: операционные системы снова стали маленькими...зря Таненбаум перестал переиздавать "ОС: разработка и реализация".

Могу поделиться, почему заглох мой проект.
Всё было нормально, пока всё делалось на ассемблере. Но полноценную (и особенно портируемую) ось невозможно сделать на одном ассемблере, нужен язык высокого уровня. Для этого нужен компилятор с языка, который подходит для разработки осей (всякие Java, Occam и большинство других языков отпадают по очевидным причинам). Очевидный выбор сужается до С и С++ (есть неочевидные варианты, но об этом потом).
Соответственно, нужен компилятор и, на первый взгляд кажется, что нет никаких проблем — используем Студию, если работаем под Win, и GCC, если под Линуксом. Однако при таком подходе мы жёстко укореняемся в родительской ОС и специфике конкретного компилятора и не можем сделать ось самозамкнутой, вся разработка будет вестись в родительской оси. Чисто теоретически можно портировать GCC, но на практике GCC настолько сросся с Linux, что разделить их представляется малореальным занятием, а в силу монструозности самого компилятора и невероятно трудоёмким.
Известный всем русофоб финн считает, что С++ категорически не годится для разработки ОС, потому что "да вы не представляете себе, в какой фарш превращаются визуально простые конструкции С++, это неоправданно сложный язык и бла-бла-бла". Если соглашаться с его логикой, то есть другие компиляторы, которые действительно можно полностью портировать в новую ОС — например, Tiny C Compiler.
Но я считаю, что финский грубый матерщинник глубоко ошибается по части С++, скорей всего по причине практически полного отсутствия опыта использования этого языка. С++ НАМНОГО эффективней чистого С и по моему личному опыту проекты на С++ существенно компактней, надёжней, быстрей и, главное, понятней эквивалентных проектов на чистом С. Поэтому я много лет как завязал с чистым С и выбор компиляторов возвращается к двум стандартам: VisualC vs GCC, то есть, швах.
Как следствие, я сейчас больше сосредоточен на написании в свободное время полностью ОС-независимого компилятора с языка С++ и смогу вернуться к теме разработки ОС по завершению работы над компилятором. Но написание ОС как проект никоим образом не оставляю.
И возвращаясь к теме неочевидных языков. Имея готовый компилятор с языка С++, можно его адаптировать и реализовать новый язык программирования, лишённый недостатков С++.
Очень может быть, что новый компилятор может являться коммерческим продуктом, но я пока что слабо представляю себе, как можно монетизировать эту разработку.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Чтоб сходу покончить с переходом на личности, скажу, что тот самый финн -- просто самовлюблённый дурак. Он неоднократно всякую чушь говорил по очень многим поводам, каждый раз демонстрируя своё невежество и кругозор с размахом сектора "точка". (Например, вспомнилось, что он утверждал, что то ли вообще любые драйверы, то ли драйверы файловых систем все делают только как часть ядра и никогда не делают снаружи ядра -- но это, мягко говоря, не соответствует действительности, как минимум, с первой половины 70-х годов: по меньшей мере, у RSX-11 драйверы файловых систем всегда были задачами режима пользователя, а не частью ядра).

Насчёт Це++, в общем и целом, соглашусь, но не с финном, а с Йодой. Сам по себе язык отвратительный, я люто ненавижу всё, что началось с Це (хоть и вынужден работать на этом дерьме -- инструменты-то только под него). Претензии и в плане синтаксиса, особенно объявлений, что тянется как раз с чистого Це и дальше лишь было усугублено, и к надёжности, и к пресловутому УБ (причём последнее -- это уже прямая вина комитета по стандартизации, который объявляет УБ всё подряд, даже если если Б вполне себе Д на любой сколько-нибудь разумной платформе, и следовало бы просто такие случаи чётко оговорить в стандарте). Но, если выбирать из чистого Це и Це++, я однозначно выбираю последний (собсно, на нём и пишу): дебилизм синтаксиса, ненадёжность и т.д. и т.п. у них, в общем и целом, одни и те же, но у це++ куда больше выразительных средств.

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

Ну а полноценную ОС на ассемблере сделать можно -- делали же Плюс, что понимать под ОС. Как по мне, ядро и драйверы режима ядра вполне можно (а скорей, даже нужно) писать на ассемблере -- только не надо в ядро тащить всё подряд и делать новую Вынь-11 или современный Линух. А вот то, что снаружи (условный рабочий стол и прочая гуйня) -- там да, лучше на языке высокого уровня делать, всё равно с аппаратурой напрямую оно не взаимодействует, а только с сервисами, предоставляемыми ядром, и действительно может быть на 100% переносимым (а ядро никогда таким быть не может).

Пы.Сы. Я вот за пару месяцев написал себе черновик транслятора ассемблера под ARM32 -- на це++ (в визуалстудии), без всякой экономии ресурсов и т.д., поэтому, если по-хорошему, его позднее надо будет тотально рефакторить. Причина разработки -- на ассемблере я таки пишу, свой ассемблер АРМ (Кейл) разрабатывать прекратила, и остался один ублюдочный ГНУсный, ну и ни в одном из существующих, особенно в ГНУсном, меня абсолютно не устраивают макросредства (ну и ряд других вещей сильно не нравится). Работать работает, эльфы выдаёт. Правда, пока реализованы не все директивы (нет блоков повторений, главным образом -- но и макросы, и условная трансляция уже есть), нет некоторых встроенных функций и нет системных переменных, а в плане системы команд не реализованы никакие команды, требующие наличия FPU (добавить их не проблема, просто пока они не нужны). Если б ещё работу работать не надо было...

Пы.Сы 2. А средства разработки как коммерческий проект... По-моему, сейчас это уже точно не прокатит. Вот донаты всякие с этого поиметь, наверное, можно -- но не традиционный бизнес, так сказать.

Ну да, я собс-но, тоже всегда отмечаю, что это выбор между "плохим" и "ужасным", потому и тешу надежду создания нового ЯВУ, т.к. исправлять косяки С++ можно только с потерей совместимости, и никак иначе. А если терять совместимость, то можно и остальное в мусорку выкидывать.


Мысль понятна. Речь тут о следующих факторах:
1. Зависимость в значительной степени функциональная и идеологическая. Ну, в частности, просто чтобы запустить GCC, пусть даже и с командной строки, нужно в ОС воспроизвести довольно большую часть POSIX, которую использует GCC, а я бы на хотел тащить это идеологическое старьё. Пример внутренней идеологической "странности" — линковка библиотек в соответствии с правилами *nix. Это нечто с чем-то, так как линкуемость зависит от порядка перечисления библиотек. Ситуация, когда "a.o b.o" линкуется, а на "b.o a.o" говорит, что "функция не найдена" — не баг, а "фича" *nix-ов. Ну не умели ранние *nix заново перепросматривать уже просмотренные библиотеки, и в целях совместимости эту "фичу" решили узаконить.
2. Привязанность к будущему. Предположим, что мы всё же решили портировать, но избавиться от POSIX/*nix шлама. Нельзя изменения просто добавить в кодовую базу, сообщество не примет патчи. Но GCC постоянно пилится сообществом GNU, поэтому портировать — значит навсегда ввязаться в "перепиливание" каждой новой версии GCC под свою ось.
3. Масштаб работы. Компилятор GCC содержит более 15 миллионов строк кода. Кланг конечно меньше, но порядок величины вполне сопоставим. Портирование такого монстра намного более трудоёмкая задача, чем написать компилятор с нуля. На текущий момент мой компилятор содержит 22 тысячи строк, полностью реализует лексический анализатор, препроцессор, линкер (совместим с любыми форматами объектников, прямая линковка DLL-библиотек, иконок и манифестов с командной строки), полнофункциональный ассемблер с i8080/z80. Нет парсера, проверки типов в абстрактом синтаксическом дереве, генерации кода. Скорей всего, весь компилятор с поддержкой самой последней версии стандарта будет меньше 100 тысяч строк кода.
По этим причинам я и написал, что чисто теоретически портировать можно, но лично мне такая перспектива совсем не нравится. Для этого нужно нанимать штат кодеров и ввязываться в крупный геморрой.


Колибри, что ли, полноценная ось? Вот Брусиловский пишет, что даже RSX-11M и RT-11 написана на языке FORTRAN-4. Конечно, некоторые процедуры невозможно написать без использования ассемблера, но если мы ставим целью как минимум лёгкое портирование основного функционала, даже консольного, между x86/AMD64 и ARM, то без ЯВУ никак.


Ни в коем случае. Иначе пропадает смысл написания оси.


Тут скорей надо определиться, что мы включаем в состав даже не оси, а ядра. С осью понятно — это не только ядро, но и минимальный набор утилит, которые, очевидно пилятся на ЯВУ. Но если, например, мы хотим многопользовательскую защиту, то мы не можем вынести ни межпроцессную коммуникацию, ни работу с файловой системой, ни планировщик целиком в юзерспейс (имя ввиду под юзером текущего пользователя, а не сервис). А там всё можно написать на ЯВУ. Если у нас микро/нано/пикоядро, то мы конечно можем сказать, что это всё реализуется в сервисах, а само ядро пишем на ассемблере. Но я склонен всё это называть ядром операционной системы — по функциональным, а не формальным критериям.


Как раз в порядке "потренироваться на кошечках" я и реализовал в своём компиляторе ассемблер на i8080/z80. Им успешно собираю и запускаю под эмулятором ОС CP/M. Нормального макроассемблера даже для этих архитектур нет, ASM80 содержит грубейшие ошибки, например, неправильно считает A+B*C — ошибка в приоритете выполнения операций

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ну, собсно, в Расте это и попытались сделать. Но хорошее дело браком не назовут -- и ржавчиной тоже (а если серьёзно, надо именно что отказываться от совместимости, но не пытаться впихнуть невпихуемое и решить нерешаемое -- типа полной надёжности прямой работы с адресами памяти, без чего невозможно низкоуровневое программирование).



Понял и, в общем-то, согласен. А насчёт порядка перечисления библиотек и объектников -- это, конечно, идиотизм. Многократно просматривать объектники/библиотеки умеют и штатный компоновщик RSX-11 (а ему примерно столько же, сколько и классическим униховым инструментам), и OS/360 (а он старше, грубо говоря, на 10 лет). Уних -- масдай



Нагло врёт. Обе этих системы целиком и полностью написаны на ассемблере. Исходников RT-11 у меня нет, а вот RSX-11 имеются -- могу, как говорится, предоставить. Единственная роль Фортрана там -- что в системной библиотеке объектных модулей были предусмотрены фортрано-совместимые подпрограммы, чтобы дёргать системные вызовы прямо из Фортрана (или, например, из Паскаля, который умел вызывать фортрановские подпрограммы, т.е. поддерживать его соглашения о связях, а не только свои собственные). Но, повторюсь, системы эти целиком и полностью написаны на ассемблере. Как, есно, и намного более крупная OS/360 (и тоже исходники имеются).



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

Исключение -- большие и тяжёлые драйверы, при этом не требующие прямого доступа к аппаратуре, -- типа тех же файловых систем или большей части драйверов видюх, включая компиляторы шейдеров. Их реализовать как задачи (процессы) режима пользователя, но постараться организовать эффективное взаимодействие между ними и прикладными задачами -- по возможности, с минимальным участием ядра или вообще без оного. Последнее, есно, зависит от особенностей архитектуры процессора. Скажем, на IBMовских мэйнфреймах очень эффективно можно использовать механизм множества адресных пространств и вызова программ по номерам -- они, собсно, и предназначены, чтобы задача режима "пользователь" могла вызвать некий код в другой задаче режима "пользователь", не дёргая ОС, но при этом с обеспечением проверки прав, защитой памяти и т.д. и т.п.; на IA-32 аналогичного, хотя сложней и черезжопней, можно было бы добиться с помощью сегментов и шлюзов вызова, но их в АМД64, как известно, полностью выпилили, так что на нём или, скажем, на АРМах уже никак без вызова ОС не обойтись.



О терминах не спорят, о терминах договариваются

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



Ну, с хорошими ассемблерами вообще проблема, поскольку они давно не мэйнстрим. На 8080 я вообще ничего сколько-нибудь нормального не видел -- и если те, которые работают на самом 8080, ещё могут отмазываться малыми доступными ресурсами, то кросс-трансляторы... (Впрочем, и ресурсы -- тоже отмаза; ассемблер OS/360 может успешно работать в разделе памяти 16 Кбайт, а по функционалу в плане макросредств ему трудно найти равного -- хотя синтаксис временами ужасен, а использование для всей условной трансляции, циклов и т.д. только ИФ и ГОТО порождает понятно насколько читабельный исходник Правда, если памяти у него мало, он будет нещадно насиловать диски, что медленно и печально -- но работает же.)

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

Посчитал число строк в моём компиляторе языка Оберон (т.е. компилятор писал Никлаус Вирт и опубликовал исходники, я только слегка модифицировал его для себя) 28524 строки в 50-ти файлах, средний размер числа строк в файле (приблизительно) 500. Самый большой парсер получился под 3000 строк (но там полно отладочных вставок и комментариев). По поводу семейства языков Си/Си++ в целом готов согласится. Я думаю не имеет смысла, делая что то с нуля, связываться с изначально неудачными решениями. А вот по поводу ассемблера. При всей моей любви к ассемблеру, мне доводилось писать относительно сложные вещи на нём. Должен сказать, что мне лично было это делать крайне тяжело. Поэтому соглашусь с Никлаусом Виртом, что на ассемблере делать серьёзные вещи стыдно. Кстати огромный размер GCC вероятно связан с тем, что это семейство компиляторов. Думаю, что если взять только Си/Си++, размер будет серьёзно меньше 15 миллионов строк. И да, хочу добавить, что я не профессиональный программист. Так что если какую ересь сказал, сделайте скидку

Для меня на самом деле полнейшая загадка, почему компиляторы содержат 15 миллионов строк кода, а операционные системы весят гигабайты.
Вот немного статистики:
– Компилятор SmallC содержит около 4 тысяч строк кода если взять генерацию кода только для одной архитектуры. Да, он реализует подмножество языка, генерирует ассемблерный текст и обработка ошибок крайне убогая. Можно генерировать код для четырёх архитектур (тогда размер около 6 тысяч строк), кодогенератор для каждой архитектуры в среднем около 650 строк. В качестве production grade компилятора рассматривать его нельзя, но по крайней мере можно провести нижнюю оценку размера компилятора.
– TinyC Compiler содержит почти 30 тысяч строк кода, написан на С и в принципе приближается к критериям более-менее нормального компилятора. Основные недостатки — плохая обработка ошибок, слабая оптимизация, невозможность нормальной кросс-компиляции (константная плавающая арифметика считается так, как работает центральный процессор). Для проектов микроскопического размера я вполне использую его, так как можно получить полнофункциональные EXE-файлы также микроскопического размера.

Исходя из текущей практики принято считать, что 90% объёма production grade компилятора — это оптимизация, с чем я вполне склонен согласиться. Однако это — опция, которую можно бесконечно допиливать. Таким образом, чистый объём компилятора GCC, вероятно, мог бы составить 1.5 миллиона строк кода.
Далее из моей личной практики по тотальному рефакторингу разных проектов получается, что проекты в среднем сокращаются в 10 раз из-за следующих факторов: переписывание на С++ вместо С и удаление повторного использования кода — все более-менее распространённые и потенциально используемые в будущих проектах алгоритмы переписываю и переношу в собственные библиотеки. Таким образом компилятор GCC мог бы сократиться ещё в 10 раз до примерно 150 тысяч строк кода. Но GCC исторически содержит исторически устаревшую архитектуру компиляции, которую невозможно обновить без тотального рефакторинга проекта. Это могло бы дать ещё 2-3 кратное сокращение объёма. Таким образом приходим к выводу, что нормальный полнофункциональный production grade компилятор можно уместить в объём 100 тысяч строк без качественной оптимизации кода.
Свой компилятор я писал изначально ориентируя его на production grade, в нём качественная обработка ошибок, параллельная компиляция, прекомпиляция заголовков в памяти, полная архитектурная независимость (вся плавающая арифметика эмулируется в соответствии с работой целевой машины) и оценка на основе экстраполяции даёт примерно тот же объём кода, что и оценка при полном рефакторинге GCC и статистики других компиляторов. То есть, в 100 тысяч строк можно получить шикарный функционал, не уступающий по большинству параметров (кроме оптимизации) существующим компиляторам.

ПыСы. Вообще-то я лукавлю, утверждая что сейчас в моём компиляторе только 22 тысячи строк, так как не считаю мои компиляторо-независимые библиотеки, а там сейчас больше 50 тысяч строк. Из них около 20 тысяч было в своё время выделено из проектора компилятора в независимую часть — там вся арифметика (числа неограниченного размера, рациональная арифметика, эмуляция плавающей запятой), поддержка параллельных вычислений, блокировки, аллокирование памяти специального вида, поддержка endianness, работа со строками, абстрактные структуры данных, автоматическое освобождение памяти и много чего другого. Но по хорошему это всё должно входить в системные библиотеки, включая саму ОС.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Сильно сомневаюсь. Бо́льшая часть компилятора не зависит от языка. К языку жёстко привязан только лексический анализатор, парсер и (специфика C/C++) препроцессор.
Лексический анализатор в моём компиляторе занимает всего-навсего тысячу строк (кстати, почему-то почти ровно в 10 раз меньше, чем в Clang). Препроцессор потяжелей, 4 тысячи строк, но в большинстве языков его нет. Кстати, препроцессор даёт примерную оценку на размер парсера, так как в препроцессоре тоже есть свой парсер.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>