goldov1 писал(а):
Привет всем на форуме, являюсь новичком в теме Operating system design, делаю первые шаги в данной теме, а также ассемблере и "железе" (электронике)
И, судя по следующей части Вашего сообщения, пока что сваливаете всё в одну кучу, а надо бы чётко разделить одно от другого. "Design" -- это
проектирование, т.е. продумывание и описание некоего изделия (ОС в данном случае) на концептуальном уровне, затем -- на уровне подсистем, модулей и т.д. Заканчивается же проектирование разработкой конкретных алгоритмов для решения той или иной частной задачи, выделенной в процессе проектирования из общей. Например, если мы рассматриваем операционную систему, то проект на самом верхнем уровне -- это описание концепции всей системы в целом, далее идут описания общих принципов работы отдельных подсистем, ниже -- модулей, составляющих эти подсистемы, и в самом низу -- ключевых алгоритмов, реализуемых теми или иными модулями. (Понятно, что не всегда можно, да и не всегда нужно превращать проект в нечто жёстко формализованное и т.п.; например, нет смысла расписывать общеизвестные алгоритмы или даже целые подсистемы, если планируется в целом опираться на другой, уже известный проект).
А вот после проектирования (ну или параллельно с ним, но с некоторым отставанием) идёт реализация проекта. Если говорить о программировании, то можно выделить стадии кодирования (coding), т.е. перевода спроектированного с "человеческого" языка на какой-либо язык программирования; тестирования и отладки. Понятно, что все эти стадии тесно связаны между собой, да и с проектированием тоже.
Насколько могу понять, под первыми шагами в "ассемблере" Вы имеете в виду именно изучение самого языка программирования и получение навыков его использования, т.е. кодирования и отладки программ. К осеписательству это прямого отношения не имеет, да и начинать изучать ассемблер лучше после того, как уже научились неплохо программировать на каком-либо языке высокого уровня. Причина проста: ассемблер требует большого внимания к деталям, а удерживать одновременно в голове и всякие мелочи, относящиеся к языку, и параллельно разбираться с основами программирования вообще (алгоритмами, структурами данных и т.п.) банально тяжело. Вот когда человек уже освоил "алгоритмистику", можно и за ассемблер браться: тогда он, ставя перед собой задачу, уже будет знать, как её надо решить алгоритмически, и ему надо будет лишь разобраться с тем, как её закодировать на ассемблере.
Что же касается электроники, то это вообще отдельная область. Хороший программист вовсе не всегда может стать хорошим электронщиком, и наоборот: принципы во многом различаются. (Кстати говоря, из-за этого многие проекты электронных схем на ПЛИС, создаваемые на языках описания электронных схем вроде VHDL и Verilog, получаются очень неэффективными: разработчики, пришедшие из программистов, относятся к этим языкам, как к обычным языкам программирования, а это не так).
Цитата:
Прочитал в интернете некоторые сведения по данной теме - насколько понял многие авторы дают в принципе только основные идеи о создании операционных систем (и драйверов и т.д.)- сама же аппаратная реализация (... на ассемблере (или микропрограммирование)) представляет собой скорее искусство, чем готовый рецепт (строгий алгоритм).
Аппаратная реализация -- это реализация в "железе", на уровне электронных схем. Когда нужно поменять такую реализацию (исправить ошибку или там расширить функционал), приходится переделывать схему. Это -- прямая противоположность реализации программной. Ассемблер же, как и любой язык программирования, предназначен для программной реализации алгоритмов, при этом аппаратная реализация (схема компьютера) всегда остаётся неизменной и не зависит от того, какие задачи на нём решаются.
Микропрограммирование к ассемблеру также никакого отношения не имеет. С точки зрения программиста, в т.ч. ассемблерщика, процессор -- это чистое "железо". Как он сделан реально (на жёсткой логике или с микропрограммным управлением), для программиста безразлично, поскольку он всё равно на это никак повлиять не может. Более того, разные процессоры одной и той же архитектуры могут быть реализованы совершенно по-разному: одни могут использовать микропрограммное управление, другие -- чисто схемное. На практике использование того или иного способа зависит в первую очередь от сложности архитектуры. Например, любые процессоры архитектуры IA-32 (от 80386 и до современных интеловских, АМДшных и ВИАвских) используют микропрограммное управление, поскольку их система команд сложна и запутанна, а посему неудобна для чисто аппаратной реализации. В то же время подавляющее большинство процессоров с простой и регулярной системой команд, например, ARMы, реализуются чисто схемным образом. А вот классические мэйнфреймы IBM System/360 и 370 бывали и такими, и сякими, хотя в конечном итоге чисто схемные реализации умерли. (Просто изначально, в конце 1960 - начале 70-х годов, схемная реализация была производительней, хотя и существенно сложней и дороже, а поэтому использовалась только в самых мощных машинах. Позже же путём некоторых ухищрений удалось добиться такой же, а затем и большей производительности на микропрограммном управлении).
"Строгих алгоритмов" и прочих готовых рецептов для решения сложных задач не существует и существовать не может. Более того, на "верхнем" уровне обычно не существует и единственно верного или идеального решения стоящей задачи. Любой сложный проект является комбинацией более простых, увязанных между собой в единую систему (недаром ОС называется именно
системой -- ведь это не одна простая программа, а именно система, комплекс, состоящий из многих взаимодействующих компонентов). Поэтому, собственно, и нужно проектирование, чтобы от общей постановки задачи и набора довольно расплывчатых требований (типа "создать вындовз-подобную ОС") дойти до конкретных "рецептов" её реализации, т.е. до описания конкретных алгоритмов, структур данных и их взаимосвязи.
Цитата:
а также имеются ли в интернете книги или сайты или публикации (брошюры, учебные пособия и.т.д.) о том как создавать операционную систему с нуля (на примере какого нибудь определенного(ных) микропроцессора(ов)) ?
Ну, всяких источников полно, но вот какого уровня и качества... В общем, в первую очередь надо изучать программирование вообще (те самые "алгоритмы + структуры данных = программы"), поскольку это является основой, а потом уже погружаться в конкретную предметную область, причём вникать не столько в конкретные реализации, сколько в сами идеи. Причём необходимо подходить к осмыслению достаточно критично: то, что некая идея используется в широко известной и популярной ОС, ещё не означает, что эта идея является единственно возможной или даже просто хорошей. В то же время нельзя кидаться и в обратную сторону: типа, всё существующее -- это сплошной отстой, нужны кардинально новые идеи и т.д. (На самом-то деле, за последние полвека в области системного программирования -- как и "железа", кстати -- изменения носили больше количественный, чем качественный характер; практически все реально используемые идеи были опробованы впервые ещё в 1960-70-х годах).
Цитата:
если на форуме есть участники готовые подсказать по этой тематике, то возможно ли также обсуждение попутных вопросов по ассемблеру (nasm, tasm, masm)?
Отвечать на "дурацкие" вопросы, характерные для новичков, банально надоедает: новички не кончаются, а вопросы у них одни и те же, уже неоднократно "обсосанные" со всех сторон. Поскольку сей форум посвящён достаточно узкой области -- разработке ОС, то вряд ли стоит ожидать, что здесь будут заниматься "начальным образованием", т.е. объяснять элементарные вещи, касающиеся языков программирования (в т.ч. ассемблера), базовых алгоритмов и т.д. Вот достаточно сложные вещи, прямо относящиеся к основной теме -- другое дело, но и здесь не стоит злоупотреблять, спрашивая вещи, хорошо описанные в известных источниках. Например, большинство, а может, и все активные "местные жители" могут объяснить, как работает страничный механизм процессоров архитектуры IA-32, как надо его включать, как заполнять таблицы переадресации и т.п. Но вряд ли кому из нас будет интересно пересказывать то, что нормально описано в интеловской документации. Поэтому в первую очередь надо самому работать с источниками (читать спецификации, книги и т.д.), а форум использовать для прояснения сложных моментов, обсуждения идей и т.п. -- в общем, как дискуссионный клуб, а не как школьный учебник.
Вход
Регистрация
FAQ
Поиск
