Супервизорный и пользовательский режимы работы процессора и их отличие

Автор: Пользователь скрыл имя, 13 Февраля 2012 в 10:55, курсовая работа

Описание работы

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

Содержание

Введение ………………………………………………..……………………..........5
1. Основные принципы построения операционных систем……………………..6
1.1 Принцип модульности…………..………………………………………6
1.2 Принцип особого режима .......................................................................8
1.3 Принцип виртуализации………………………………………………..9
1.4 Принцип мобильности ………………………………………………….12
1.5 Принцип совместимости ……………………………………………….14
1.6 Принцип генерируемости ……………………………………………...15
1.7 Принцип открытости …………………………………………………..16
2. Архитектура оперрационной системы………………………………………...17
3. Супервизорный и пользовательский режимы работы процессора и их
отличие…………………………………………………………………………….22
Заключение………………………………………………………………………..28
Литература…….………………………………………………………………...……29

Работа содержит 1 файл

principy_postroeniya_operacionnyh_sistem.docx

— 271.68 Кб (Скачать)

     Например, в системах Windows все аппаратные ресурсы  полностью виртуализированы, и прямой доступ к ним со стороны прикладных (и системных обрабатывающих) программ однозначно запрещен. В системах Windows NT/2000/XP даже были введены понятия HAL (Hardware Abstraction Layer — уровень абстрагирования  аппаратуры) и HEL (Hardware Emulation Layer — уровень  эмуляции аппаратуры), и этот шаг  очень помогает в реализации идей переносимости (мобильности) операционной системы.

    1. Принцип мобильности

     Мобильность, или переносимость, означает возможность  и легкость переноса операционной системы  на другую аппаратную платформу. Мобильная  операционная система обычно разрабатывается  с помощью специального языка  высокого уровня, предназначенного для  создания системного программного обеспечения. Такой язык помимо поддержки высокоуровневых  операторов, типов данных и модульных  конструкций должен позволять непосредственно  использовать аппаратные возможности  и особенности процессора. Кроме  этого, такой язык должен быть широко распространенным и реализованным  в виде систем программирования, которые  либо уже имеются на целевой платформе, либо позволяют получать программные  коды для целевого компьютера. Другими  словами, этот язык системного программирования должен быть достаточно распространенным и технологичным. Одним из таких  языков является язык С. В последние  годы язык C++ также стал использоваться для этих целей, поскольку идеи объектно-ориентированного программирования оказались плодотворными  не только для прикладного, но и для  системного программирования. Большинство  современных операционных систем были созданы именно как объектно-ориентированные.

     Обеспечить  переносимость операционной системы  достаточно сложно. Дело в том что  архитектуры разных процессоров  могут очень сильно различаться. У них может быть разное количество рабочих регистров, причем часть регистров может оказаться контекстно-зависимыми, как это имеет место в процессорах с архитектурой ia32. Различия могут быть и в реализации адресации. Более того, для операционной системы важной является не только архитектура центрального процессора, но и архитектура компьютера в целом, ибо важнейшую роль играет подсистема ввода-вывода, а она строится на дополнительных (по отношению к центральному процессору) аппаратных средствах. В таких условиях сделать эффективным код операционной системы при условии создания его на языке типа C/C++ невозможно. Поэтому часть программных модулей, которые более всего зависят от аппаратных особенностей процессора, от типов поддерживаемых данных, способов адресации, системы команд и других важнейших моментов, разрабатывается на языке ассемблера. Очевидно, что модули, написанные на языке ассемблера, при переносе операционной системы на процессор с иной архитектурой должны быть написаны заново. Зато остальная (большая) часть кода операционной системы может быть просто перекомпилирована под целевой процессор. Именно по этому принципу в свое время была создана операционная система UNIX. Относительная легкость переноса этой системы на другие компьютеры позволила сделать ее одной из самых распространенных. Для обеспечения мобильности был даже создан стандарт на интерфейс прикладного программирования, названный POSIX (Portable Operating System Interface for Computer Environments — интерфейс прикладного программирования для переносимых операционных систем).

     К сожалению, на самом деле далеко не все операционные системы семейства UNIX допускают относительно простую  переносимость созданного для них  программного обеспечения, хотя сами они  и поддерживают такую переносимость. Основная причина тому — отход  от единого стандарта API — POSIX. Очевидно, что платой за универсальность, прежде всего, является потеря производительности при выполнении операций ввода-вывода и вычислений, связанных с этими  операциями. Поэтому ряд разработчиков  шли и до сих пор идут на отказ от принципа мобильности, поскольку не всегда следование этому принципу экономически оправдано.

     Если  при разработке операционной системы  сразу не следовать принципу мобильности, то в последующем очень трудно обеспечить перенос на другую платформу  как самой операционной системы, так и программного обеспечения, созданного для нее. Но даже если изначально в спецификации на операционную систему  заложить требование легкой переносимости, то не значит, что его в последующем  будет просто реализовать. Подтверждением тому является тот же проект OS/2-WindowsNT. Как известно, проект Windows NT обеспечивал  работу этой операционной системы на процессорах с архитектурой ia32, MIPS, Alpha (DEC), PowerPC. Однако в последующем трудности с реализацией этого принципа привели к тому, что нынешние версии операционных систем класса Windows NT (Windows 2000/XP) уже создаются только для процессоров с архитектурой ia32 и не поддерживают MIPS, Alpha и Power PC.

     1.5 Принцип совместимости 

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

     Необходимо  разделять вопросы двоичной совместимости  и совместимости на уровне исходных текстов приложений. Двоичная совместимость  достигается в том случае, когда  можно взять исполняемую программу  и запустить ее на выполнение на другой операционной системе. Для этого  необходимы: совместимость на уровне команд процессора, совместимость на уровне системных вызовов и даже на уровне библиотечных вызовов, если они являются динамически связываемыми.

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

     Гораздо сложнее достичь двоичной совместимости  между процессорами, основанными  на разных архитектурах. Для того чтобы  один компьютер выполнял программы  другого (например, программу для  персонального компьютера типа IBM PC хочется выполнять на компьютере типа Мае от фирмы Apple), этот компьютер  должен работать с машинными командами, которые ему изначально непонятны. Одним из средств обеспечения  совместимости программных и  пользовательских интерфейсов является соответствие стандартам POSIX. Эти стандарты  позволяют создавать программы  в стиле UNIX, которые впоследствии могут легко переноситься из одной  системы в другую.

     1.6 Принцип генерируемости

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

     1.7 Принцип открытости

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

     Этот  принцип иногда трактуют как расширяемость  системы. К открытым операционным системам прежде всего следует отнести UNIX-системы и, естественно, системы Linux. 
 
 
 
 
 
 
 
 

  1. Архитектура операционной системы

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

     Функциональная  сложность операционной системы  неизбежно приводит к сложности  ее архитектуры, под которой понимают структурную организацию ОС на основе различных программных модулей. Обычно в состав ОС входят исполняемые  и объектные модули стандартных  для данной ОС форматов, библиотеки разных типов, модули исходного текста программ, программные модули специального формата (например, загрузчик ОС, драйверы ввода-вывода), конфигурационные файлы, файлы документации, модули справочной системы и т. д.

     Большинство современных операционных систем представляют собой хорошо структурированные  модульные системы, способные к  развитию, расширению и переносу на новые платформы. Какой-либо единой архитектуры ОС не существует, но существуют универсальные подходы к структурированию ОС.

     Ядро и вспомогательные  модули ОС

     Наиболее  общим подходом к структуризации операционной системы является разделение всех ее модулей на две группы:

  • ядро — модули, выполняющие основные функции ОС; 
  • модули, выполняющие вспомогательные функции ОС.

     Модули  ядра выполняют такие базовые  функции ОС, как управление процессами, памятью, устройствами ввода-вывода и  т. п. Ядро составляет сердцевину операционной системы, без него ОС является полностью неработоспособной и не сможет выполнить ни одну из своих функций.

     В состав ядра входят функции, решающие внутрисистемные задачи организации  вычислительного процесса, такие  как переключение контекстов, загрузка/выгрузка станиц, обработка прерываний. Эти  функции недоступны для приложений. Другой класс функций ядра служит для поддержки приложений, создавая для них так называемую прикладную программную среду. Приложения могут  обращаться к ядру с запросами  — системными вызовами — для  выполнения тех или иных действий, например для открытия и чтения файла, вывода графической информации на дисплей, получения системного времени и  т. д. Функции ядра, которые могут  вызываться приложениями, образуют интерфейс  прикладного программирования — API.

     Функции, выполняемые модулями ядра, являются наиболее часто используемыми функциями  операционной системы, поэтому скорость их выполнения определяет производительность всей системы в целом. Для обеспечения  высокой скорости работы ОС все модули ядра или большая их часть постоянно  находятся в оперативной памяти, то есть являются резидентными.

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

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

     ПРИМЕЧАНИЕ 

     Термин  «ядро» в разных ОС трактуется по-разному. Одним из определяющих свойств ядра является работа в привилегированном  режиме. Этот вопрос будет рассмотрен в следующем разделе.

     Остальные модули ОС выполняют весьма полезные, но менее обязательные функции. Например, к таким вспомогательным модулям  могут быть отнесены программы архивирования  данных на магнитной ленте, дефрагментации диска, текстового редактора. Вспомогательные  модули ОС оформляются либо в виде приложений, либо в виде библиотек  процедур.

     Поскольку некоторые компоненты ОС оформлены  как обычные приложения, то есть в виде исполняемых модулей стандартного для данной ОС формата, то часто бывает очень сложно провести четкую грань  между операционной системой и приложениями (рис. 2.1).

     Решение о том, является ли какая-либо программа  частью ОС или! нет, принимает производитель ОС. Среди многих факторов, способных повлиять на это решение, немаловажными являются перспективы того, будет ли программа иметь массовый спрос у потенциальных пользователей данной ОС.

     Некоторая программа может существовать определенное время как пользовательское приложение, а потом стать частью ОС, или  наоборот. Ярким примером такого изменения  статуса программы является Web-браузер  компании Microsoft, который сначала  поставлялся как отдельное приложение, затем стал частью операционных систем Windows NT 4.0 и Windows 95/98, а сегодня существует большая вероятность того, что  по решению суда этот браузер снова  превратится в самостоятельное  приложение.

Информация о работе Супервизорный и пользовательский режимы работы процессора и их отличие