системой AS/400, так как в ней не предусмотрены большинство функций, присущих другим ОС.
В главе 1 мы определили ОС как набор программ, управляющих системными ресурсами и предоставляющих базу для написания прикладных программ. Мы также оговорили, что законченный набор API для написания приложений для AS/400 — это MI, высокоуровневый машинный интерфейс. Таким образом, на вторую часть вопроса мы ответили. Осталось решить, где же находятся программы, управляющие системными ресурсами.
И снова ответ «OS/400» будет неверен. Компоненты традиционной ОС выполняют такие функции как управление памятью, процессами, программами и вводом-выводом. Но, обычно, эти низкоуровневые функции сильно зависят от аппаратуры и тесно связаны с нижележащими физическими структурами. Например, компонент управления памятью должен «знать» точную конфигурацию и характеристики иерархии памяти. Независящий от технологии интерфейс MI не обладает этими качествами. Следовательно, управление памятью должно осуществляться ниже MI, OS/400 же, наоборот, расположена выше. Следовательно, ни одна из таких аппаратно-зависимых компонент не может быть в ее составе, этого не допускает основное условие задачи — независимость от технологии.
Итак, благодаря расположению аппаратно-зависимых компонентов ниже MI, последний защищает прикладные программы и OS/400 от аппаратных изменений. ПО операционной системы, расположенное ниже MI, называется LIC (licensed internal code).
Давайте еще раз взглянем на структуру AS/400. Теперь очевидно: OS/400 состоит из объектов и программ поверх MI, а LIC составляют структуры данных и программы ниже MI. Таким образом, LIC связывает MI и аппаратуру. Фактически, ОС AS/ 400 — сочетание OS/400 и LIC. Получается, что AS/400 представляет собой пирог, в котором OS/400 играет роль глазури, а LIC — начинки между слоями.
В последние годы такую нижнюю часть ОС в других системах стали называть ядром. Есть много определений того, что именно относится к ядру операционной системы. Некоторые педанты могли бы сказать, что LIC содержит гораздо больше функций операционной системы, чем, обычное ядро. И все же термин ядро наиболее удобнен для описания функций ОС, реализованных ниже MI.
Очевидно, что некоторые компоненты ОС, такие как управление памятью, реализованы в LIC. Для других компонентов это не столь очевидно. Возьмем, например, базу данных. Некоторым ее частям необходима информация о физических дисковых устройствах и о пересылке данных в системе, другие же — могут быть написаны аппа-ратно независимо. Проектировщики обязаны решить, где разместить ПО базы данных — целиком в OS/400, целиком в LIC или и там, и там.
Рискуя забежать вперед (подробно мы рассмотрим MI в главе 4) должен отметить, что, говоря о разделении на OS/400 и LIC, я имею в виду объекты MI, реализованные в LIC. Позже мы подробней остановимся на системных объектах MI, реализованных в LIC, и на объектах OS/400, реализованных только MI.
Конечно, все функции OS/400 присутствуют в LIC в том смысле, что они должны использовать MI для обращения к аппаратуре. Но часто инструкция на ЯВУ после преобразования в соответствующую форму MI транслируется в команды PowerPC (или старого IMPI) напрямую, без каких-то особых структур данных или вызовов процедур LIC. Считать, что некоторая системная функция реализована OS/400, а не LIC, можно в тех случаях, если реализующий ее код видим OS/400 и необходимые структуры данных находятся в объектах OS/400 или в их видимых частях.
На рисунке 3.1 показано распределение функций ОС между OS/400 и LIC. Некоторые функции, такие как управление планированием заданий, могут быть реализованы в основном в OS/400, так как мало зависят от аппаратуры. Другие, такие как поддержка устройств — частично в OS/400, а частично в LIC. Общие характеристики устройств могут поддерживаться OS/400. Например, информация о том, что устройство является принтером, не привязывает прикладную программу к конкретному принтеру. А вот информация о деталях потока данных принтера вызывает подобную привязку и должна использоваться в LIC, ниже MI.
Некоторые аппаратно-независимые функции ОС также реализованы ниже MI, например, защита. Эта функция не зависит от аппаратуры, и таким образом может быть осуществлена целиком в OS/400 поверх MI. Однако реализация части защиты ниже MI обусловлена требованиями безопасности. Подробнее о том, как осуществляется общесистемная защита в OS/400, а контроль доступа к системным ресурсам — в LIC, мы поговорим в главе 7.
Подобно защите, большинство функций ОС реализованы частично над, а частично — под MI. Даже отдельный компонент некоторой функции ОС может быть реализован по обе стороны этой границы. На рисунке 3.1 показаны некоторые компоненты базы данных и их распределение относительно MI.
Другая причина расположения некоторой функции или части ее ниже MI — производительность. Общий принцип таков: чем более функция аппаратно-зависима, тем лучше ее можно настроить для максимальной производительности. Реализация ниже MI не гарантирует повышение производительности для всех функций, но в некоторых случаях может помочь. Недостаток такого подхода — увеличение объема кода ОС, зависящего от аппаратуры.
Ранее микропрограммирование было определено как технический прием, при котором программирование внутреннего компьютера служит цели эмуляции операций внешней вычислительной архитектуры. Соответствующее ПО часто называют микрокодом.
В System/38 было два разделенных IMPI слоя микрокода ниже MI: горизонтальный микрокод HMC (Horizontal Microcode) и вертикальный микрокод VMC (Vertical Microcode)[ 27 ] . Самым низким уровнем был HMC, использовавший специализированный набор микрокоманд, исполняемый аппаратурой процессора непосредственно. Он содержал микропрограммируемый эмулятор, выполнявший команды IMPI. В состав HMC были также включены некоторые функции ОС самого низкого уровня. HMC был спроектирован так, чтобы обеспечить высокопроизводительный параллелизм работы процессора. Из-за этого ЯВУ для написания такого кода не существовало, а программирование было очень сложным и требовало много времени.
Вторым слоем, расположенным под MI, но над IMPI, был VMC. В этом слое содержались те аппаратно- зависимые функции ОС, которые не были реализованы в HMC. VMC был написан частично на специализированном ЯВУ, разработанным внутри IBM для системного программирования, и частично на ассемблере IMPI. Он не был микрокодом в традиционном смысле; а представлял собой самый нижний уровень ПО ОС.
Ядро операционной системы System/38 было названо микрокодом во избежание коммерческих проблем, типичных для 60-х годов. Тогда среди компьютерных гигантов, включая IBM, была распространена следующая практика: связывать получение системного ПО с требованием покупать фирменную аппаратуру. Так продолжалось до тех пор, пока различные фирмы ни создали множество компьютеров, совместимых с мэйнфреймами IBM (сегодня, мы назвали бы их клонами), для продажи по более низкой цене. Производители совместимой аппаратуры получали прибыль только в том случае, если бы покупатели могли приобретать ОС IBM без аппаратных средств. Под угрозами судебных преследований IBM согласилась в будущем не привязывать ПО к своим компьютерам.
С System/38 проблема связанных продаж ПО и аппаратуры возникла вновь. Мы хотели получить систему, единственным внешним интерфейсом которой был бы MI. Если бы мы продавали только аппаратные
