Развитие нового семейства ЭВМ раньше обычно начиналось с рассмотрения семантической модели структуры программы и поддерживающего машинного языка. Хорошим примером могут служить серии фирмы IBM 704, ..., 7094. Эта серия вычислительных машин, возможно и с недостаточно развитой программной структурой, получила широкое распространение с развитием языка Фортран. Более поздние модели обладали и более широкими возможностями. В них увеличилось число различных компонент, улучшилась связь с системами ввода-вывода, появились устройства с более высокими скоростями, возросло число индексных регистров и т. д. Однако в этих машинах сохранялся (и вынужден был сохраняться) основной принцип работы - компиляция/выполнение фортраноподобных объектных программ. (Эта серия изжила себя еще до реализации многопроцессорного принципа.)
Можно привести ряд других примеров, в которых архитектура разработанных серий вычислительных машин базировалась или сильно зависела от некоторой модели структуры программы. Так, серия GE/Honeywell Multics основывалась на семантической модели этапа выполнения программ, написанных на языке ПЛ/1. В Burroughs В5500, В6700, . . . , В7800 прототипом послужила модель программы этапа выполнения, написанной на расширенном языке Алгол. Это расширение помимо обычного Алгола-60 позволяло подсоединять подпрограммы, асинхронные задачи и имело средства взаимодействия с системными программами.
Процессор i432, подобно этим ранним архитектурам, также базируется на семантической модели структуры программы. Однако в отличие от своих предшественников i432 не основывается на модели некоторого конкретного языка программирования. Вместо этого основной целью разработчиков было обеспечение непосредственной поддержки на этапе выполнения как для абстрактных данных (т. е. программирование с абстрактными типами данных), так и для доменно-ориентированных операционных систем. Основная особенность архитектуры i432 заключается в том, что оба этих требования могут быть удовлетворены с использованием общей семантической модели, известной как модель объекта. В данном разделе мы объясним концепцию абстрактных данных, рассмотрев для этого объектно-ориентированную методологию программирования, а также рассмотрим связанные с этим принципы проектирования объектно-базированных операционных систем.
Объектно-базированное программирование в отличие от общепринятого метода, основанного на управлении, характеризуется тем, что программа большей частью описывает создание, манипуляцию и взаимодействие внутри набора независимых и хорошо определенных структур данных, называемых объектами. Метод, основанный на управлении, рассматривает программу как управляющую последовательность событий (действий) над множеством ее структур данных. В обоих случаях задачей программы является преобразование некоторого заданного набора значений данных из некоторой входной или начальной формы к некоторой выходной или конечной форме. Хотя это отличие на первый взгляд может показаться несколько неестественным или надуманным, имеющиеся отличия тем не менее весьма существенны. Здесь мы попытаемся объяснить это вкратце, а в последующих главах постепенно будем приводить более подробное объяснение и особо остановимся на этом вопросе в гл. 2 и 3.
В общепринятом программировании, основанном на методе, базирующемся на управлении, программист обнаруживает, что по мере возрастания сложности программы становится все труднее и труднее сохранять полное представление о всей последовательности (или последовательностях) выполняемых этой программой действий. С этой точки зрения весьма полезным оказывается разбивка длинных последовательностей на короткие группы. (Фактически хороший программист никогда не создает непрерывные последовательности недопустимо большой длины, разбивая их на серию подпрограмм.)
К сожалению, данные, обрабатываемые этими подпрограммами, не разбиваются аналогичным образом на ряд независимых единиц. Большинство данных находятся в глобальных структурах, к которым имеют доступ все подпрограммы. Следовательно, большинство удобств, ожидаемых от подпрограмм, никогда не реализуются. Суть проблемы - в числе подпрограмм и их зависимости от формы и целостности разделяемых структур данных. По мере того как это число растет, становится все более трудным, если не невозможным, организовывать подпрограммы и данные в подходящие (изоморфные) подструктуры, например в строго иерархическом порядке, даже при использовании алголоподобных языков, аналогичных Паскалю.
В объектно-базированном программировании, напротив, работа начинается со связывания одной-единственной структуры данных с фиксированным набором подпрограмм. Единственными операциями, определяемыми над данным объектом, являются соответствующие подпрограммы. Согласно терминологии языка Ада, структура данных называется объектом, а связанный с ней набор операций - "пакетом". Обычно один набор таких операций "общего пользования" определяется и делается доступным всем компонентам программы, имеющей доступ к этому объекту данных. Эти общедоступные операции имеют строго определенные спецификации ввода-вывода; тела их подпрограмм и любых подпрограмм, от которых эти тела могут в дальнейшем зависеть, можно обособить и сделать полностью скрытыми. Пакет также может быть использован для скрытия представления об объекте с тем, чтобы подпрограммы из других пакетов не могли пропустить эти подпрограммы общего пользования и непосредственно манипулировать с объектом.
Такое обособление называется абстрактным типом данных и может привести к значительному упрощению при составлении программы, т. е. сделать ее более понятной, корректной и надежной. Также обеспечивается гибкость (и переносимость), поскольку части объектов, их представления и операции общего пользования могут быть изменены или заменены другим набором частей.
Говоря более формально [29], абстрактные данные позволяют нам сфокусировать свое внимание только на тех атрибутах объекта данных или класса их, которые задают имена и определяют абстрактные значения операций, связанных с такими объектами. Мы не указываем атрибуты, описывающие представление этих объектов и реализацию связанных с ними операций, в терминах других объектов и операций.
Вышеописанные концепции, которые до сих пор использовались для введения понятия абстрактного типа данных как конструкций современных языков программирования высокого уровня, впервые появились в понятии конструкций типа класс из языка Симула 67 [7, 16]. Рассмотрение конструкций, относящихся к классу Симула, привело к появлению ряда предложений по введению абстрактных данных в современные языки программирования [3, 39, 42, 67, 68]. Последние достижения в развитии языка Ада, использующего подобную конструкцию, обязаны этим ранним исследованиям.
Параллельно с развитием понятия абстрактных данных были также проведены большие исследования в области изучения принципов работы операционных систем. Некоторые из этих достижений обязаны чисто теоретическим исследованиям, однако большинство из них базируется на разработке, внедрении, наблюдении и использовании реальных систем. Извлеченные уроки охватывали достаточно широкий диапазон. В частности, важное значение уделялось следующим темам:
Приведенный список нельзя назвать исчерпывающим. В настоящий момент по прежнему проводятся исследования по вопросам проектирования и создания более совершенных систем. Недавний прогресс в этой области обязан главным образом универсальному признанию того факта, что принципы грамотного инженерного дизайна и конструирования применимы также и к программированию операционных систем.
Полагая, что приведенный список представляет собой "идеальный" набор свойств операционной системы, большинство экспериментальных исследований концентрировали свое внимание на минимизации числа элементарных функций, на которых строится система, - так называемый "базовый" подход, а также на "поуровневом" построении последующих функций системы таким образом, чтобы она приобретала строго иерархическую структуру [20]. (Аппаратная поддержка такой организации была впервые предложена в системе Multics [28].) Обнаружение того факта, что не все функции операционной системы подчиняются тем же самым иерархическим принципам, привело разработчиков операционных систем к рассмотрению множественных, но при этом полностью независимых иерархий, называемых доменами [62, 63].
Почти в это же время велись споры о том, что строгая иерархичность при создании всей системы существенно ограничит ее гибкость на верхнем, ориентированном на пользователя, уровне [69]. Было замечено, что каждый из доменов операционной системы ответствен за определенные структуры данных, называемые "объектами", которые в общем случае соответствуют понятию ресурса в системе (например, страница, файл и процесс). Формально объект может быть определен как абстракция некоего ресурса и рассматриваться в виде следующей тройки [70]:
(уникальное имя, тип, предстваление)
Уникальное имя отличает объект от всех других объектов. Уникальность имени может распространяться как на пространство (в котором находится объект), так и на время (в пределах жизни системы, в которой был создан этот объект). Тип объекта отражает природу представляемого им ресурса. Представление содержит некоторый объем информации, связанный с этим объектом. Представление объекта может включать в себя приватные структуры данных, а также ссылки на другие объекты, имеющие форму уникальных имен. Представление также включает в себя определенные формуляры и пределы, ограничивающие объем информации в объекте.
Экспериментальные системы доказали, что организация физических ресурсов и информации в вычислительных системах в виде объектов оказывает значительный эффект на управление этими ресурсами. Схемы управления проще в разработке, реализации и использовании. Индивидуальные ресурсы легче описывать, создавать (распределять), уничтожать (удалять), защищать от случайного или намеренного несанкционированного использования, а также ими легче управлять. Возможность скрывать (и защищать от прямого доступа) ненужные детали представления и реализации является автоматическим следствием "объектного" подхода в подобных системах.
Помимо того что экспериментальные исследования продемонстрировали логическую обоснованность объектов и доменов как организационной модели современной операционной системы, они также весьма убедительно показали, что без непосредственной аппаратной поддержки они слишком неэффективны для того, чтобы быть коммерчески выгодными. Большинство экспериментальных работ по операционным системам переместилось в другие области в ожидании необходимых нововведений в аппаратной части.
Проектирование архитектуры i432 началось с задачи создания аппаратной поддержки для доменно-базированной защиты и для абстрактных данных; другими словами, с задачи создания объектно-ориентированной архитектуры. После работы над этой задачей в течение некоторого времени было установлено, что логическим и желательным обобщением этой цели будет использование абстрактных данных как фундаментальной структуры всей архитектуры. Это обобщение привело к появлению того, что мы называем объектно-базированной архитектурой.
Хотя объектно-базированная архитектура была главным образом ориентирована на решение проблем исполнения, связанных с объектно-базированными операционными системами при использовании обычной аппаратной части, эта архитектура фактически находится в разработке уже около двадцати лет. Считается, что она началась с развития архитектур, использующих дескрипторы [12, 30, 34], которым обязано появление концепции и внедрение поддержки сегментированной виртуальной памяти. Эволюция затем продолжилась, начиная с появления систем, реализующих концепцию возможностей, в частности возможностей адресации [14, 17, 22-26, 30, 64, 65], и вплоть до текущей концепции, рассматривающей объекты как абстрактные ресурсы и берущей свое начало в системе HYDRA [69, 70]. Возможностью называется санкционированный доступ к некоторому конкретному объекту. Менеджеры объектов выделяют возможности для доступа к объектам тем программным единицам, которым они требуются. Архитектура i432 в довольно высокой степени моделирует структуру объектов и концепции управления ими системы HYDRA, используя при этом аппаратную поддержку возможностей.
Перед тем как перейти к более подробному обсуждению, приводящемуся в гл. 4-6 и 9, вкратце ознакомимся с природой архитектурной поддержки, использованной в системе i432 для объектно-базированного системного проектирования. Эта поддержка обеспечивает следующее:
Вводя концепцию объекта в архитектуру, разработчики системы i432 предполагали ее использование для высокоэффективного управления системной конфигурацией и ее индивидуальными ресурсами (с точки зрения администратора ЭВМ). Кроме этого, предполагалось использование этой концепции для общей поддержки абстрактных данных с целью упрощения организации программы (с точки зрения системных и прикладных программистов). Потенциально сильная связь между управлением системой, с одной стороны, и управлением программой и данными - с другой, пока еще не была полностью реализована в других системах. В самом деле, по прежнему остается спорным, является ли этот эффект "близнецов", использованный при создании системы i432, привлекательным архитектурным требованием [66]. Выбранная здесь точка зрения заключается в том, что обеспечение архитектурной поддержки, гарантирующей использование объектов в определенных терминах (что фактически является обеспечением возможности программирова ния с использованием абстрактных данных), автоматически обеспечивает наличие механизмов защиты адресного пространства, необходимых для соответствующего управления системными ресурсами.
|
|
|
|