Общая концепция[]
TODO
Написать общую концепцию разработки ос на ассемблере
Мнения участников[]
Dron[]
Разрабатывать операционную систему целиком на ассемблере - это утопия. Ничего серьезного из этого не получится. Можно, конечно, попытаться написать на ассемблере ядро. Это может даже вполне получиться. Но со временем понимаешь, что это не самый оптимальный путь развития, так как это:
- Непереносимо.
- Громоздко.
- Трудно в сопровождении.
Некоторые мотивируют это тем, что, дескать, повышается производительность. Это миф.
Но, с другой стороны, любой уважающий себя программист, тем более системный, должен знать ассемблер. Это знание позволяет лучше понимать, как работают программы.
Поэтому не смею никого отговаривать. Единственное, о чем напомню: даже отдельное ядро - это весьма большой проект. Это сотни килобайт исходных текстов и сотни тысяч строк кода. Чтобы во всем этом не запутаться, вырабатывайте в себе и в своих исходных текстах строгий стиль. Исходники должны или говорить, или быть подробно прокомментированы.
Свое ядро я потом все-таки перепишу на C, а, возможно, даже на C++. Совсем без ассемблера в любом случае не получится.
SadKo[]
Лично я считаю, что ОС на ассемблере годится лишь для развития навыков написания ОС, хороший способ разобраться в том, как функционирует та или иная аппаратура, и каково её взаимодействие с прикладным программным обеспечением. Однако по мере роста ядра становится всё сложнее и сложнее его модификация. При написании ОС собенно важно то, чтобы любой её компонент подвергался рефакторингу с минимальным воздействием на остальные компоненты. С ассемблерными ядрами это очень-очень сложно.
Лично я не жалею, что даже и не пытался писать своё ядро сразу на C/C++. Когда моё ядро ещё входило в коммерческий проект, мне хватило мытарств с загрузчиком этого ядра (система работала как embedded, поэтому грузиться приходилось из flash-памяти и осуществлять сhip-селекты ОЗУ), который писался на ассемблере. Пусть он даже был и небольшого объёма (пара тысяч строк), но в нём уже тогда было сложно разбираться.
Писать на C ядро легче и понятнее: большую часть рутины на себя берёт компилятор. Однако, когда дело доходит до более сложных систем, опять же возникают проблемы с расширяемостью: например, забыл куда-то из трёх мест прописать функцию, и думаешь, почему не работает.
Писать на C++ ядро посложнее, чем на C, но в этом есть свои плюсы. Уже не приходится задумываться о низкоуровневых таблицах функций и всяких ухищрениях - проблема решается за счёт наследования и полиморфизма. Компилятор автоматически генерирует необходимые таблицы виртуальных функций, и нам уже не следует о них заботиться. Однако, не следует также и "перебарщивать" и втягиваться в абстракцию, используя шаблоны. Подобное решение приводит к резкому разрастанию кода и увеличению времени компиляции. Но это не значит, что шаблоны надо полностью исключить, так как иногда они бывают очень полезны. В общем, это отдельная тема для разговора.
SII[]
Не соглашусь с уважаемыми участниками обсуждения сразу по нескольким пунктам.
Dron утверждает, что "Разрабатывать операционную систему целиком на ассемблере - это утопия. Ничего серьезного из этого не получится". Однако как быть с системами 1950-70-х годов? Их что, не существовало? Или они не были серьёзными?
Глупо спорить с тем, что ОС на ассемблере является непереносимой. Однако следует заметить, что и ОС на ЯВУ нельзя просто так "в лоб" перенести на ЭВМ иной архитектуры: в любом случае потребуются переделки, связанные с особенностями аппаратуры управления памятью, прерываниями и вводом-выводом.
Громоздкость и трудность сопровождения ПО на ассемблере, с моей точки зрения, серьёзно преувеличиваются. Фактически при чётком соблюдении принципа "разделяй и властвуй" и при должном документировании проекта сопровождать ПО на ассемблере если и сложнее, чем на ЯВУ, то ненамного.
Заявление "Некоторые мотивируют это тем, что, дескать, повышается производительность. Это миф" также ошибочно. Самый оптимальный код, а значит, наивысшая производительность, может быть получен только на ассемблере: никакой оптимизирующий транслятор не выполнит свою работу лучше человека. Другое дело, что сам по себе факт написания программы на ассемблере ещё не гарантирует, что она будет более "скорострельной", чем созданная на ЯВУ, поскольку ручная оптимизация -- работа весьма трудоёмкая и требующая очень хорошего понимания не только системы команд, но и ряда технических аспектов, например, того, как работает кэш-память процессора.
Ещё один мой "кирпичик в огород" Dron'а касается "сотен тысяч строк" исходного кода. Всё зависит от ОС и, опять-таки, кривизны рук (и мозгов) тех, кто её делал. Например, даже в ранних версиях OS/360 было что-то вроде 2 млн. строк на ассемблере; правда, в состав этой ОС, а значит, в указанное число входят и утилиты, и трансляторы -- а они занимают немало. Действительно, такой громадный объём написать очень сложно, а в одиночку -- нереально. Однако можно привести и противоположный пример. Одна из самых развитых ОС для PDP-11 (наш аналог -- СМ-3/4/1300/1600/1420/1425) -- RSX-11M, у нас "перекрещённая" в ОС-РВ (т.е. операционная система реального времени). Это полноценная многозадачная многопользовательская система, обладающая практически всеми необходимыми функциями API, включая межзадачное взаимодействие, управление памятью и т.п. В один момент времени с ней может работать сразу несколько человек (с разных терминалов, естественно), причём, понятное дело, система не даёт им вредить друг другу, т.е. реализована многопользовательская защита. Так вот, ядро этой системы занимает несколько десятков килобайт (подчёркиваю: не мегабайт, а килобайт -- меньше, чем значительно более примитивная MS DOS). Отсюда легко установить и объём исходного кода ядра: несколько десятков тысяч строк на ассемблере (PDP-11 -- 16-разрядная машина, коды команд имеют длину 2, 4 и 6 байт). Написать ядро подобного уровня в одиночку вполне реально за разумный срок.
Что касается сложности рефакторинга, о котором говорит SadKo, то здесь также всё зависит от "кривизны" реализации. Главное -- это чёткое разделение функций разных модулей системы, документирование, недопущение "паразитных связей" и т.п. Но если не придерживаться этих принципов, никакой ЯВУ не спасёт.
В общем, моё мнение таково: реализация ядра ОС на ассемблере не только технически возможна, но и вполне уместна, только надо чётко определиться с тем, что должно входить в ядро, а что -- нет, и не допускать его "разбухания" за разумные пределы. А вот программирование всей ОС в наше время целиком на ассемблере -- это уже перебор. Например, я не вижу смысла реализовывать команды типа dir или copy на ассемблере: их скорость возрастёт крайне незначительно, объём серьёзно тоже не уменьшится, так не проще ли написать их на ЯВУ?