Здесь могла бы быть моя специализация
0,0
рейтинг
26 сентября 2011 в 17:22

Как начать и не бросить писать ОС из песочницы

Очередной велосипедЧитая Хабр в течении последних двух лет, я видел только несколько попыток разработки ОС (если конкретно: от пользователей pehat и iley (отложено на неопределённый срок) и Igor1024 (не заброшено, но пока больше походит на описание работы защищённого режима x86-совместимых процессоров, что бесспорно тоже необходимо знать для написания ОС под x86); и описание готовой системы от alman (правда не с нуля, хотя в этом нет ничего плохого, может даже наоборот)). Мне почему-то думается, что почти все системные (да и часть прикладных) программисты хотя бы раз, но задумывались о написании собственной операционной системы. В связи с чем, 3 ОС от многочисленного сообщества данного ресурса кажется смешным числом. Видимо, большинство задумывающихся о собственной ОС так никуда дальше идеи и не идёт, малая часть останавливается после написания загрузчика, немногие пишут куски ядра, и только безнадёжно упёртые создают что-то отдалённо напоминающее ОС (если сравнивать с чем-то вроде Windows/Linux). Причин для этого можно найти много, но главной на мой взгляд является то, что люди бросают разработку (некоторые даже не успев начать) из-за небольшого количества описаний самого процесса написания и отладки ОС, который довольно сильно отличается от того, что происходит при разработке прикладного ПО.

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


Как не надо начинать

Don't do thatПросьба не воспринимать следующий ниже текст как явную критику чьих-то статей или руководств по написанию ОС. Просто слишком часто в подобных статьях под громкими заголовками акцент делается на реализации какой-то минимальной заготовки, а подаётся она как прототип ядра. На самом деле следует задумываться о структуре ядра и взаимодействии частей ОС в целом, а тот прототип рассматривать как стандартное «Hello, World!»-приложение в мире прикладного ПО. В качестве небольшого оправдания этих замечаний, следует сказать, что ниже есть подраздел «Hello, World!», которому в данном случае уделено ровно столько внимания сколько нужно, и не больше.

Не надо писать загрузчик. Умные люди придумали Multiboot Specification, реализовали и подробно описали, что это такое и как его использовать. Не хочу повторяться, просто скажу, что это работает, облегчает жизнь, и его надо применять. Спецификацию, кстати, лучше прочесть полностью, она небольшая и даже содержит примеры.

Не надо писать ОС полностью на ассемблере. Это не так чтобы плохо, скорее наоборот — быстрые и маленькие программы всегда будут в почёте. Просто так как этот язык требует значительно больших усилий на разработку, то использование ассемблера приведёт только к уменьшению энтузиазма и, как следствие, к забрасыванию исходников ОС в долгий ящик.

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

Подготовка

preparationsДля начала как всегда следует ознакомиться с общей теорией, дабы иметь какие-то представления о предстоящем объёме работ. Хорошими источниками по рассматриваемому вопросу являются книги Э. Таненбаума, которые уже упоминались в других статьях о написании ОС на Хабре. Также есть статьи с описанием существующих систем, и есть различные руководства/рассылки/статьи/примеры/сайты с уклоном в разработку ОС, ссылки на часть из которых приведены в конце статьи.

После начального ликбеза необходимо определиться с главными вопросами:
  • целевая архитектура — x86 (real/protected/long mode), PowerPC, ARM, ...
  • архитектура ядра/ОС — монолит, модульный монолит, микроядро, экзоядро, разные гибриды
  • язык и его компилятор — C, C++, ...
  • формат файла ядра — elf, a.out, coff, binary, ...
  • среда разработки (да, это тоже играет не последнюю роль) — IDE, vim, emacs, ...

Далее следует углублять знания согласно выбранному и по следующим направлениям:
  • видео память и работа с ней — вывод в качестве доказательства работы необходим с самого начала
  • HAL (Hardware Abstraction layer) — даже если поддержка нескольких аппаратных архитектур и не планируется грамотное отделение самых низкоуровневых частей ядра от реализации таких абстрактных вещей как процессы, семафоры и так далее лишним не будет
  • управление памятью — физической и виртуальной
  • управление исполнением — процессы и потоки, их планирование
  • управление устройствами — драйвера
  • виртуальные файловые системы — для обеспечения единого интерфейса к содержимому различных ФС
  • API (Application Programming Interface) — как именно приложения будут обращаться к ядру
  • IPC (Interprocess Communication) — рано или поздно процессам придется взаимодействовать

Инструменты

toolsУчитывая выбранные язык и средства разработки следует подобрать такой набор утилит и их настроек, которые в будущем позволят путём написания скриптов, максимально облегчить и ускорить сборку, подготовку образа и запуск виртуальной машины с проектом. Остановимся немного детальнее на каждом из этих пунктов:
  • для сборки подойдут любые стандартные средства, как то make, cmake,… Тут в ход могут пойти скрипты для линкера и (специально написанные) утилиты для добавления Multiboot-заголовка, контрольных сумм или для каких-либо других целей.
  • под подготовкой образа имеется ввиду его монтирование и копирование файлов. Соответственно, формат файла образа надо подбирать так, чтобы его поддерживала как утилита монтирования/копирования, так и виртуальная машина. Естественно, никто не запрещает совершать действия из этого пункта либо как финальную часть сборки, либо как подготовку к запуску эмулятора. Всё зависит от конкретных средств и выбранных вариантов их использования.
  • запуск виртуальной машины труда не представляет, но нужно не забыть сначала отмонтировать образ (отмонтирование в этом пункте, так как до запуска виртуальной машины реального смысла в этой операции нет). Также не лишним будет скрипт для запуска эмулятора в отладочном режиме (если таковой имеется).

Hello, World!

Hello, World!Если все предыдущие шаги выполнены, следует написать минимальную программу, которая будет загружаться как ядро и выводить что-нибудь на экран. В случае обнаружения неудобств или недостатков выбранных средств, необходимо их (недостатки) устранить, ну или, в худшем случае, принять как данность.

На данном шаге необходимо проверить как можно больше возможностей средств разработки, которые планируется использовать в будущем. Например, загрузку модулей в GRUB или использование в виртуальной машине физического диска/раздела/флешки вместо образа.

После того как этот этап прошёл успешно, начинается настоящая разработка.

Обеспечение run-time поддержки

runtimeТак как предлагается писать на языках высокого уровня, следует позаботиться об обеспечении поддержки части средств языка, которые обычно реализуются авторами пакета компилятора. Например для C++, сюда относятся:
  • функция для динамического выделения блока данных на стеке
  • работа с heap
  • функция копирования блока данных (memcpy)
  • функция-точка входа в программу
  • вызовы конструкторов и деструкторов глобальных объектов
  • ряд функций для работы с исключениями
  • стаб для нереализованных чисто-виртуальных функций
  • ...

При написании «Hello, World!» отсутствие этих функций может никак не дать о себе знать, но по мере добавления кода, линкер начнёт жаловаться на неудовлетворённые зависимости.

Естественно, тут же следует упомянуть и о стандартной библиотеке. Полная реализация не является необходимой, но основное подмножество функций реализовать стоит. Тогда написание кода будет значительно привычнее и быстрее.

Отладка

debuggingНе смотрите, что об отладке говорится ближе к концу статьи. На самом деле это очень серьёзный и непростой вопрос в разработке ОС, так как обычные средства тут неприменимы (за некоторым исключением).

Можно посоветовать следующее:
  • само собой разумеющееся, отладочный вывод
  • assert с немедленным выходом в «отладчик» (см. следующий пункт)
  • некоторое подобие консольного отладчика
  • проверить не позволяет ли эмулятор подключать отладчик, таблицы символов или ещё что-нибудь

Без встроенного в ядро отладчика поиск ошибок имеет вполне реальный шанс превратится в кошмар. Так что от его написания на некотором этапе разработки просто никуда не деться. А раз это неизбежно, то лучше начать его писать заранее и таким образом значительно облегчить себе разработку и сэкономить довольно много времени. Важно суметь реализовать отладчик независимым от ядра образом, чтобы отладка минимальным образом влияла на нормальную работу системы. Вот несколько типов команд, которые могут быть полезны:
  • часть стандартных отладочных операций: точки останова, стек вызовов, вывод значений, печать дампа, ...
  • команды вывода различной полезной информации, вроде очереди исполнения планировщика или различной статистики (она не так бесполезно как может показаться сначала)
  • команды проверки непротиворечивости состояния различных структур: списков свободной/занятой памяти, heap или очереди сообщений

Развитие

develДальше необходимо написать и отладить основные элементы ОС, которые в данный момент должны обеспечить её стабильную работу, а в будущем — лёгкую расширяемость и гибкость. Кроме менеджеров памяти/процессов/(чего-нибудь ещё) очень важным является интерфейс драйверов и файловых систем. К их проектированию следует подходить с особой тщательностью, учитывая всё разнообразие типов устройств/ФС. Со временем их конечно можно будет поменять, но это очень болезненный и подверженный ошибкам процесс (а отладка ядра — занятие не из лёгких), поэтому просто запомните — минимум десять раз подумайте над этими интерфейсами прежде чем возьмётесь за их реализацию.

Подобие SDK

SDKПо мере развития проекта в нём должны добавляться новые драйвера и программы. Скорее всего уже на втором драйвере (возможно определённого типа)/программе будут заметны некоторые общие черты (структура каталогов, файлы управления сборкой, спецификация зависимостей между модулями, повторяющийся код в main или в обработчиках системных запросов (например если драйвера сами проверяют их совместимость с устройством)). Если так и есть, то это признак необходимости разработки шаблонов для различного типа программ под вашу ОС.

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

Дальнейшие действия

continueЕсли кратко, то: читать про операционные системы (и в первую очередь именно про их устройство), развивать свою систему (темпы на самом деле не важны, главное — не прекращать совсем и возвращаться к проекту время от времени с новыми силами и идеями) и естественно исправлять в ней ошибки (для нахождения которых надо иногда запускать систему и «играться» с ней). Со временем процесс разработки будет становиться всё легче и легче, ошибки будут встречаться реже, а вы будете зачислены в список «безнадёжно упёртых», тех немногих, которые несмотря на некоторую абсурдность идеи разработки собственной ОС, всё же сделали это.

Полезные ссылки

На Хабре:
Пишем свою ОС: Выпуск 1
Пишем свою ОС: Выпуск 2
Продолжаем написание операционок. Шаг за шагом
Что такое Protected Mode и с чем его едят
Учим систему страничной адресации и обработке прерываний
Начинаем разговор о многозадачности
Память и задачи

Другие источники с большим количеством информации по разработке ОС:
wasm.ru
sysbin.com
wiki на osdev.org
iakovlev.org
Bona Fide OS
@xaizek
карма
38,0
рейтинг 0,0
Здесь могла бы быть моя специализация
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (55)

  • +24
    До определения с главными вопросами, необходимо определиться с наиглавнейшим: Нафига писать собственную ОС, если это только не проект на университетском курсе?
    • +32
      Как насчёт самообразования? Одного из хобби? Или того, что написание ОС позволит хорошо понять принципы работы тех же Linux/Windows и научится эффективнее их использовать?
      • +14
        Для самообразования можно выбрать что-то более полезное для себя и общества. А понимание принципов работы какой-либо оси через написание своей — тонкий извращенный метод. По общим принципам операционок есть довольно качественная литература (которую кстати желательно изучить и при написании своей), а детали, ньюансы работы у каждой системы свои и для их понимания надо изучать именно эту систему. Например для начала можно найти книжку «Ядро Linux» и воспользоваться ей — будет быстрее и эффективнее.
        • +2
          Насчёт извращения может Вы и правы. Просто занимаясь одной теорией или изучая существующие системы многое останется за кадром, как мне кажется.
        • +4
          Для общества — возможно. Для себя — разве что собираешь вступить в команду, разрабатывающую какую-то ось, тогда надо разбираться с конкретно с нею. А если это просто хобби, то почему бы и не написать свою?
      • +2
        Написание и самообразование/понимание — абсолютно разные вещи. Как я уже говорил, принципы ОС изучаются на соответствующем курсе computer science. Очень часто тамошняя курсовая работа и есть написание простейшей «ОС». Простейшей в том понимании, что сконцентрироваться на всех аспектах, сервисах, надежности операционной системы одному человеку не под силу.
        Для образования можно спокойно учить исходники Линукс (там сконцентрированны тонны опыта, неориднарных решений и вся полнота работающей годы и на всем железе системы). Можно взять простые ОС на С, которые можно понять и изучить за несколько вечеров.
        Писать свою для понимания? Неа, не стоит.
    • +6
      Интересно чтобы с нами со всеми было если бы именно так подумали создатели винды или линукса, юникса, макоси или ос/2!?
      Энштейн как-то сказал: «Все знают, что это невозможно. Но вот приходит невежда, которому это неизвестно — он-то и делает открытие.»
      Думаю Гейтс или Торвальдс просто бы рассмеялись вам в лицо.

      Вот не понимаю я хабр… комментарий который должен быть глубоко в минусе — на самом деле в плюсе.
      • +1
        Ну да, ну да, здоровый энтузиазм, понимаю. Только скажите, уважаемый, к какому такому открытию готовит статья? Вот сразу после слов: «После начального ликбеза необходимо определиться с главными вопросами:», что должны уяснить себе Настоящие Хабровчане (тм)? Вы действительно уверены, что архитектура и формат файлов — это главные вопросы создания ОС?! Мне очень не хочется разрушать светлую мечту стать вторым гейтсом или торвальдсом, но все перечисленные главные вопросы на самом деле даже не второстепенны.
        ЗАЧЕМ плодить сущности? — вопрос главный. На какие средства разрабатывать проект в десятки тысяч человеко-лет? — вопрос главный. Где взять тысячи сообщников/последователей, чтобы проект не длился десятки тысяч лет? — вопрос главный. Почему бы не оказать помощь существующему проекту вместо разбазаривания времени — тоже главный вопрос. А пафос с Энштейном — это для школоты, мечтающей внезапно взять джекпот, повторив неожиданный успех Торвальдса написанием очередного миллионного псевдоядра.
        • +1
          ага… Товальдс прямо вот так взял и накатал ядро с первого раза и без ошибок!!! Ну да… ага…

          Если «пафос» с Энштейном для школоты — то вы… в его словах смысл как раз полностью противоположный, но вам боюсь его не понять.
          • +1
            Вы не ответили про открытие. Какое открытие здесь предполагается? Вот я могу вам открыть кое-что: ядро ОС — 1/100500 часть всей работы. А теперь в качестве ответной любезности, откройте и вы мне что-нибудь.

            И последнее: курс про операционные системы и количество наглядного материала сегодня и в то время, когда учился Торвальдс — две большие разницы.
        • +4
          Вы всё ещё пытаетесь найти ответ на вопрос, который не имеет к данной заметке никакого отношения. Её идея «КАК начать и не бросить в связи с нетипичностью процесса разработки», а не почему, зачем или с какой целью… Именно по этому вопросы целей и не упоминаются в тексте. Предполагается, что читатель сам знает причину по которой ему стоит этим заниматься (как я) или не стоит (как Вы).
          • 0
            Нет, ответ на вопрос «как не бросить?» напрямую и безоговорочно связан с вопросом «зачем?». Если Вы заметили, я нигде не советовал НЕ писать свою ОС. Но ответить себе на вопрос «с какой целью я пишу эту ОС», построить план работ (и ужаснуться ее количеству :), понять насколько высок порог выхода новой системы в мир, не говоря о минимальной популярности, — ИМХО, нужно обязательно и гораздо раньше выбора компилятора. Иначе — очередная недокурсовая, убитое время и максимум — слегка удовлетворенное хобби, не более. Но 100% брошенный проект.
            • 0
              sarcasm mode on
              Да действительно уж лучше я счастливого фермера на HTML5 наваяю! Всяко полезней для общества.
              sarcasm mode off
        • +1
          Все Ваши вопросы актуальны при условии, что исходный вопрос стоит не «как написать свою ОС», а «как написать свою актуальную и коммерчески успешную ОС». Но вопрос так не стоит. Вопросы о сообщниках, популяризации и временных/финансовых затратах можно смело оставить за кадром.
          • 0
            Нет, исходный вопрос автора остался: как дописать свою ОС и не сойти при этом с ума и не умереть с голоду, образно говоря, разумеется. Про популяризацию и коммерциализацию речи даже не идет. Очень грубо говоря, автор хочет собрать свой автомобиль, приготовив разводной ключ (долго выбирая цвет ключа), пару гаек для мотора и кусок крыла. При этом нигде в его описании процесса создания автомобиля нет ни намека на чертежи, примерный объем работ и их стоимость. При этом он утверждает, что описание содержит в себе секрет как не бросить сборку автомобиля. А уже заготовленные детали и инструмент доказывают как раз обратное: автор понятия не имеет каких временных и материальных ресурсов заберет автомобиль до своей первой поездки. Откуда же он знает, что не бросит? Согласитесь, о друзьях, разъезжающих на серийных автомобилях, будущих салонах и агентах, говорить и вовсе рано. При этом никто(!) не подвергает сомнению способность самого автора в конце концов собрать этот автомобиль. Люди чего только не делают из принципа или любви к искусству.
      • +1
        >Интересно чтобы с нами со всеми было если бы именно так подумали создатели винды или линукса, юникса, макоси или ос/2!?

        А с чего вы взяли, что они об этом не подумали?
        Что касается Торвальдса, то у него был вполне конкретный ответ на вопрос «нафига писать свою ОС?» — «Чтобы иметь свободную/бесплатную юникс-подобную ОСь». Он даже вроде как-то говорил, что если бы BSD стала свободной чуть раньше, то он не начал бы писать Linux.
        • 0
          Насколько я помню Товальдс делал терминал для удалённой системы, для подключения своего домашнего компьютера. Поскольку система была POSIX, то и после 2 лет отладки его терминал стал POSIX совместимый. Так как он шёл при реализации по списку вызываемых функций, то в конечном итоге получилось подобие ОС.
          • +3
            Что-то типа того, да:
            Мой эмулятор терминала обрастал наворотами. Я регулярно использовал
            его, чтобы подключиться к университетскому компьютеру и получить почту или
            поучаствовать в конференции по Minix. Беда была в том, что я хотел скачивать
            и закачивать файлы. То есть мне нужно было уметь писать на диск. Для этого
            моей программе эмуляции нужен был драйвер дисковода. А еще ей был нужен
            драйвер файловой системы, чтобы она могла вникать в организацию диска и
            записывать скачиваемые файлы.

            Одним словом, жизнь моя не блистала разнообразием. А разработка
            драйверов для дисковода и файловой системы казалась интересным делом. И я
            решил им заняться. Написал драйвер дисковода. А поскольку я хотел записывать
            файлы в файловую систему Minix, да к тому же эта система была хорошо
            документирована, я сделал свою файловую систему совместимой с системой
            Minix. Таким образом я мог читать файлы, созданные в Minix, и писать файлы
            на тот же диск, так что Minix могла читать файлы, созданные моей программой
            эмуляции терминала.
            Я крутился как белка в колесе: программирование — сон — программирование — еда (соленые сухарики) — программирование — сон — программирование — душ (на скорую руку) — программирование. К концу работы
            стало ясно, что моя программа превращается в операционную систему. И я стал
            думать о ней не как о программе эмуляции терминала, а как об операционной
            системе. Этот сдвиг произошел, вероятно, в дурмане одного из затянувшихся
            сеансов программирования. Было это днем или ночью? Не знаю. Сижу я в своем
            старом халате и работаю с программой эмуляции, снабженной дополнительными
            функциями. А потом вдруг понимаю, что этих функций стало так много, что
            программа превратилась в рабочую версию операционной системы.

            И уже после этого он решил раздобыть спецификации POSIX и начал реализовывать сисколы (сначала подряд по списку, потом по мере надобности).
  • +1
    Хочу сказать только одно: бросил писать, т.к. понял что без контента (прикладных и нужных программ) она обречена на провал. Возможно, все мы рано или поздно приходим к этой мысли. Нет контента — нет ОС. Нет ОС — нет контента. Она просто не нужна.
    • 0
      Полностью согласен, без контента толку от ОС — ноль. Вот только я предлагаю не бросать разработку по этой причине, а наоборот продолжать — чтобы со временем обустроить ОС до годности к использованию (пусть и ограниченному). Ведь никто не гонит со сроками, а реализуя то что есть в привычных ОС (не обязательно писать всё с нуля, можно и портировать), можно узнать много нового (и никогда не знаешь, какой опыт и где может пригодиться).
      • +3
        Да, согласен. Со многим согласен. Кроме одного. Я как-то вечером сидел и курил, размышляя об этом и пришел к такой мысли — на сколько я хочу слить свою жизнь в унитаз? Понял — что не очень-то хочу. Поэтому занялся другими проектами. По сути — это сливание своего времени (жизни в унитаз), если не появится модели производства контента (востребованного) для этой ОС. А это в свою очередь значить либо конкурировать с гигантами (предлагая лучшие сервисы или другие усовершенствования для работы уже существующих программ), либо сделать ее узкоспециализированной (МСВС или еже с ней). Ни то ни другое без чуда — просто не реально. Кому я нужен с таким опытом? Пошел писать сайты) Да, это (написание ОС) намного интереснее и почти мечта. На то она и мечта…
        • +1
          Если мечта написать свою ось, то почему бы нет. Если мечта написать востребованную другими ось, то тут, да, в одиночку только время зря потратишь, скорее всего.
        • +5
          Любое хобби можно рассматривать как слив времени в унитаз, но если не будет хобби, то зачем тогда жить?
    • 0
      Следование группе стандартов POSIX и перенос стандартной библиотеки позволяют не беспокоиться по поводу софта.

      Пример: быстро развивающийся проект Pedigree OS, в котором участвует автор довольно известного туториала — Джеймс Моллой.

      К тому же, все вышесказанное характерно только для декстопных ОС, в то время как миниатюрные ядра систем реального времени и ОС для встраиваемых решений часто рассматриваются в качестве фреймворка для создания собственного продукта. Здесь уже проблема отсутствия ПО не стоит, решающими факторами оказываются характеристики данного решения.
  • 0
    Тут ещё на Хабре как-то Денис Попов писал о создании «своей ОС»…
    Эпичный был топик.
    • +6
      Я к тому, что не все «попытки разработки ОС» хабраюзерами в начале статьи указаны.
  • +1
    Можете посоветовать какие-либо материалы по экзоядру и library OS? А то по определённым причинам заинтересовался данной темой, но найти хороших текстов в Интернете не получилось.
    • +1
      К сожалению не могу, так как больше микроядрами интересуюсь, да и с информацией по экзоядрам как-то сложнее. Но сам бы с удовольствием ознакомился с пободными материалами, так что надеюсь, кто-нибудь всё же подскажет что-то по теме.
    • +2
      Можете посмотреть сорцы XOmB-а на github, правда он написан на D.
    • 0
      Вот тут есть описание архитектуры экзоядерной ОСи. Где-то на хабре есть перевод первой части, дальше не переводил — тема оказалась невостребованной.
  • 0
    Таннебаума забыли посоветовать
    • 0
      Неправда, в «Подготовке» он упомянут. В конце нету просто из-за того что в остальных подобных статьях его очень часто указывают.
  • 0
    IMHO появление новой ОС обусловлено новыми технологиями в аппаратной части и в построении современных программных языков (грубо, появление новых компиляторов для этих языков). Хороший пример Актив Оберон, Go, Zenon и операционные системы на их основе типа AOS и пр.

    В той же лаборатории ETH создали Interactive Paper, что должно привести к новой парадигме ОС.
  • 0
    У меня вопрос. Я совсем не знаю ассемблера, но люблю C++. Можно ли написать свою ОС, не используя ассемблер вообще?
    • 0
      «не используя ассемблер вообще» нельзя. Но минимально необходимый объём ассемблера выучить нетрудно. А ассемблер тут действительно необходим только для непосредственного взаимодействия с аппаратурой и организации других низкоуровневых вещей вроде системных вызовов. Для всего (ну, почти всего) этого пишутся удобные обёртки, а дальше уже их используют в С++.

      Так что не стоит из-за незнания ассемблера отказываться от попыток, он не так уж и страшен.
      • 0
        Ассемблер зависит от аппаратной платформы, именно поэтому, часто реализацию ассемблера и дизассемблера выносят в отдельные модули. Как в Актив Оберон ОС.

        Такой подход делает систему переносимой на другие аппаратные платформы.
        • 0
          Да, я это понимаю, и про HAL упоминал. Просто хотелось явно указать, что код на ассемблере можно раз написать, запрятать в высокоуровневые конструкции и «забыть» о нём.
          • 0
            К сожалению нельзя, разные платформы с разными параллельными конвейерами и разными форматами команд ассемблера требуют парсинга и оптимизации. Эта задача часто решается на уровне регулярных выражений.

            Если же спустится на уровень операционных кодов или микрокода и написания тестов, то мы получаем ещё несколько уровней абстракции. IMHO, решение — унификация кода на уровне HDL. Тем более, переферия требует часто именно этого уровня.
      • 0
        >> Я совсем не знаю ассемблера, но люблю C++
        Это зря. Ассемблер — самый простой язык для освоения.
        Если есть голова и понимание основ машинной арифметики, то вряд ли это займёт больше часа.
        Даже абсолютному новичку в программировании для начала хватит осознания что такое регистры и как организована память.
        Мнемоники не сложно посмотреть в справочнике.
        • 0
          > Ассемблер — самый простой язык для освоения.

          Удивительное высказывание, которое я вижу уже не в первый раз. Примитивы ассемблера выучить просто: всего-то 20 регистров и 30 команд. Но сила ассемблера — в разнообразии их сочетания, в разнообразии сочетания их сочетаний, которое дает разнообразие разнообразий… И это только для одного конкретного ассемблера, под конкретную архитектуру. И я молчу про граничные условия, которые возникают, если в однобайтовый регистр попытаешься запихнуть двухбайтовое число… Слишком самообманчиво думать, что если вы знаете, как поместить число в регистр, вы знаете ассемблер.
          • 0
            >> в однобайтовый регистр попытаешься запихнуть двухбайтовое число
            Транслятор ругнётся. Да и обычно синтаксис явно определяет разрядность операндов,
            так что это просто невозможно сделать.

            >>Слишком самообманчиво думать, что если вы знаете, как поместить число в регистр, вы знаете ассемблер.
            Это уже не знание языка, а умение на нём программировать. Как и в любом другом случае.
            Изучив конкретную архитектуру в теории, нужно написать много тысяч строк кода, чтобы писать нормально и не делать глупостей. Я сейчас ограничиваюсь интринсиками, т.к. тупо нет времени вылизывать асм код. В игрострое весьма жесткие временные рамки.
            • 0
              > Это уже не знание языка, а умение на нём программировать.

              Знание языка — это умение на нем программировать. И никак иначе. В вашем случае это не знание языка, а знание его синтаксиса и команд — в лучшем случае. Потому что уж очень часто мне попадаются люди, которые говорят, что они знают язык А, но на деле — они его не знают, писать на нем хорошие и аккуратные программы не могут, хотя синтаксис им знаком, да. Это никак нельзя назвать знанием языка.

              Вы уже много лет пишете на ассемблере, и потому-то вам эта задача кажется простой. Любая преодоленная трудность кажется простой. В Интернете уже, кстати, поднимался вопрос: Assemby first programming language, люди сходятся на мнении, что это не язык для новичка.
              • 0
                >> В вашем случае это не знание языка, а знание его синтаксиса
                Да, я именно о знании синтаксиса и говорил. Для асм-куска длинной в 10-100 строк, о котором говорится в данном топике не нужно быть гуру ассемблера.

                >> Любая преодоленная трудность кажется простой
                Да не было никаких трудностей.
                Я просто электронникой занимался в детстве, а регистры и триггеры для меня это естественная среда. Ассемблер стал натуральным продолжением моих знаний.
                Когда я смотрю / пишу код, думаю на уровне конвеера CPU.
                • 0
                  Ну вот для вас и не трудность, — это чистой воды субъективизм. Естественно, что не только я, — но и другие с вами не согласны, потому что в большинстве других случаев ассемблер совсем не «самый простой язык для освоения». И по этой фразе нельзя сказать, что вы думали исключительно о синтаксисе, о регистрах и командах.
                  • 0
                    Знание языка это очень общее понятие. Вы вкладываете лишний смысл туда.
                    Вот вы знаете русский? А «Войну и Мир 2» сможете написать? Это ортогонально.

                    >> писать на нем хорошие и аккуратные программы не могут

                    Синтаксис и подход к программированию это одно, а способность, как вы говорили, «писать хорошие и аккуратные программы» это совершенно отдельная вещь, которая слабо связана с языком программирования.
                    Тот кто пишет «хорошие и аккуратные программы» на одном языке, вряд ли будет на другом языке писать «плохие и хаотичные».

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

                    А в ассемблере кроме простого синтаксиса и нет ничего больше.
                    Там _нечего_ учить, кроме как не зависящие от языка алгоритмы и специфичные для конкретного CPU способы повышения эффективности кода. Не нужно читать 1000 страничный стандарт C++.

                    • 0
                      > Тот кто пишет «хорошие и аккуратные программы» на одном языке, вряд ли будет на другом языке писать «плохие и хаотичные».

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

                      Я не вкладываю в то понятие ничего лишнего. Это известная и признанная аксиома. А вот возьмите тот же LISP, — у него синтаксиса не больше, чем в ассемблере. Но находятся задачи, чьи решения от разных лисперов так отличаются, что это рождает внутриязыковые споры. Однако ж, чего там изучать? Дерево вызовов, — вот и все…
  • +1
    не заброшено. у нас пока других забот хватает.
    • +1
      ОК, это только радует. Заменил на «отложено на неопределённый срок».
  • 0
    Оси пишут так мало потому что это как правило бессмысленно. На это уходит куча сил и времени, а результат бесполезен практически (кроме полученных знаний). Потому что есть Linux/Freebsd/Unix/Windows, которые развивает большое количество человек. Смысл писать еще одну ось?
    • 0
      А почему нет? Неужели обязательно должны быть конкретные планы на выход на рынок и т.д.? По-моему можно делать что-то ради интереса.

      Трата времени — да, но речь не идёт о разработке в ущерб чему-то более важному. И уж тем более никто не предлагает писать убийц Linux/Freebsd/Unix/Windows, это было бы просто смешно (хотя вероятно возможно, при наличии соответствующих ресурсов).
  • +2
    А про KolibrioOS уже забыли? Система живет, и потихоньку развивается!
    • 0
      Не замечал, чтобы развитие было активным.
      • +3
        Оно есть, даже под отдельные решения (eBox-3300MX) идет разработка.
    • 0
      Не забыли, просто не встречал упоминаний о ней на Хабре (хотя сейчас поиском нашёл). Да и указывал только те, которые тут подробно описывались. Плюс KolibriOS, как довольно успешный проект, не вяжется с фразой «попыток разработки ОС».

      Надеюсь система будет развиваться и дальше!
  • +1
    Спасибо за статью, вдохновил.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.