GeoSELECT.ru



Компьютеры / Реферат: Обзор технологии CORBA (Компьютеры)

Космонавтика
Уфология
Авиация
Административное право
Арбитражный процесс
Архитектура
Астрология
Астрономия
Аудит
Банковское дело
Безопасность жизнедеятельности
Биология
Биржевое дело
Ботаника
Бухгалтерский учет
Валютные отношения
Ветеринария
Военная кафедра
География
Геодезия
Геология
Геополитика
Государство и право
Гражданское право и процесс
Делопроизводство
Деньги и кредит
Естествознание
Журналистика
Зоология
Инвестиции
Иностранные языки
Информатика
Искусство и культура
Исторические личности
История
Кибернетика
Коммуникации и связь
Компьютеры
Косметология
Криминалистика
Криминология
Криптология
Кулинария
Культурология
Литература
Литература : зарубежная
Литература : русская
Логика
Логистика
Маркетинг
Масс-медиа и реклама
Математика
Международное публичное право
Международное частное право
Международные отношения
Менеджмент
Металлургия
Мифология
Москвоведение
Музыка
Муниципальное право
Налоги
Начертательная геометрия
Оккультизм
Педагогика
Полиграфия
Политология
Право
Предпринимательство
Программирование
Психология
Радиоэлектроника
Религия
Риторика
Сельское хозяйство
Социология
Спорт
Статистика
Страхование
Строительство
Схемотехника
Таможенная система
Теория государства и права
Теория организации
Теплотехника
Технология
Товароведение
Транспорт
Трудовое право
Туризм
Уголовное право и процесс
Управление
Физика
Физкультура
Философия
Финансы
Фотография
Химия
Хозяйственное право
Цифровые устройства
Экологическое право
   

Реферат: Обзор технологии CORBA (Компьютеры)



Содержание

Введение 3
1. Брокер Объектных Заявок 4
2. Язык определения интерфейсов 7
3. Сетевая модель CORBA 8
4. Объектная модель CORBA 9
5. Клиенты и серверы CORBA 10
6. Стабы и скелетоны 10
7. Основные объектные службы CORBA 11
8. Универсальные средства CORBA 13
Заключение 15
Список использованных источников 16

Введение

CORBA (Common Object Request Broker Architecture) – Общая Архитектура
Брокера Объектных Запросов - это стандарт, набор спецификаций для
промежуточного программного обеспечения (ППО, middleware) объектного типа.
Задача ППО, как известно, заключается в связывании программных приложений
для обмена данными. Эволюция ППО - это путь от программ передачи информации
между конкретными приложениями, через средства импорта- экспорта данных и
организацию мостов между некоторыми приложениями, через SQL, RPC (Remote
Procedure Call), TP мониторы (Transaction Proceesing) обработки транзакций,
Groupware - управление различными неструктурированными данными (тексты,
факсы, письма электронной почты, календари и т.д.) и, наконец, MOM -
Message-Oriented Middleware (асинхронный обмен сообщениями между сервером и
клиентом), к созданию распределенных компьютерных систем. Элементы этих
систем могут взаимодействовать друг с другом как на одной локальной машине,
так и по сети. CORBA позволяет организовать единую информационную среду,
элементы которой могут общаться друг с другом, вне зависимости от их
конкретной реализации, "прописки" в распределенной системе, платформы и
языка их реализации [1]. CORBA образует нижний слой архитектуры
промежуточного слоя, обеспечивающий технологическую платформу
интероперабельности. Семантика объектов на этом уровне не принимается во
внимание [8].



1 Брокер Объектных Заявок


Брокер Объектных Заявок (Object Request Broker – ORB) - это
промежуточное ПО, которое устанавливает клиент-серверные отношения между
объектами в распределенной компьютерной среде [1]. ORB обеспечивает
механизмы, позволяющие объектам посылать или принимать заявки, отвечать на
них и получать результаты, не заботясь о положении других объектов в
распределенной среде и способе их реализации. ORB отвечает за поиск
реализации объекта-сервера для выполнения заявки, подготовку реализации
этого объекта к приему заявки и за передачу данных, являющихся результатом
выполнения заявки [8]. Брокер представляет собой механизм, позволяющий
объектам выдавать заявки и получать ответы прозрачным образом. Благодаря
этому обеспечивается интероперабельность между приложениями на различных
аппаратных платформах в неоднородных распределенных средах. Необходимо
подчеркнуть, что речь идет здесь о технической интероперабельности в том
смысле, как это понятие интерпретируется в [3].
Интероперабельность брокеров распространяет эту возможность на
случаи, когда объекты-клиенты и объекты-серверы ассоциированы с несколькими
однотипными или разнотипными брокерами. Под однотипными брокерами
понимаются здесь различные установки одной и той же реализации брокера
какого-либо производителя, а установки различных реализаций брокера мы
называем разнотипными брокерами.
Интероперабельность брокеров трактуется OMG как способность объекта-
клиента, управляемого брокером-1, вызывать определенные IDL-спецификациями
операции объекта-сервера, управляемого брокером-2, при условии, что брокер-
1 и брокер-2 были разработаны независимо друг от друга. Иначе говоря, такие
вызовы должны быть независимы от того, одним и тем же или разными
(возможно, разнотипными) брокерами поддерживаются взаимодействующие
объекты.
CORBA определяет среду для различных реализаций ORB, поддерживающих
общие сервисы и интерфейсы (рис.1). Это обеспечивает мобильность клиентов и
реализаций объектов по отношению к различным реализациям ORB. ORB
обеспечивает интероперабельность компонентов глобального объектного
пространства. Определения интерфейсов объектов могут быть помещены в
Репозитарий Интерфейсов (Interface Repository) двумя способами: статически
- в результате спецификации на IDL, или динамически. Репозитарий
представляет компоненты интерфейса как объекты и обеспечивает доступ к ним
в период выполнения.
При формировании заявки клиент может использовать интерфейс
динамического вызова или генерируемый компилятором IDL стаб (stub) -
локальную процедуру вызова заданной операции при обращении к ней.
Клиент может непосредственно взаимодействовать с ORB. В этом случае
ORB ищет соответствующий код реализации объекта, пересылает ему параметры
заявки и передает управление. Реализация объекта принимает параметры заявки
через сгенерированный компилятором IDL скелетон (Skeleton) и при этом может
обращаться к Объектному Адаптеру (Object Adaptor) и ORB [8]. Основная
функция объектного адаптера, используемого для реализации CORBA-объекта, -
обеспечение доступа к сервисам брокера объектных запросов. Объектный
адаптер предоставляет все низкоуровневые средства для связи объекта с его
клиентами. В число этих средств входят:
1) генерация ссылок на удаленные объекты,
2) вызов методов, определенных в IDL,
3) обеспечение безопасности взаимодействия,
4) активация и деактивация объектов,
5) установление соответствия между ссылками на удаленные объекты и
реальными экземплярами объектов,
6) регистрация объектов.
Спецификация OMG CORBA определяет базовый объектный адаптер, который
должен быть реализован во всех брокерах запросов. Basic Object Adapter
(BOA) - это набор интерфейсов для создания ссылок на удаленные объекты,
регистрации объектов, авторизации запросов и активизации приложений.
Базовый объектный адаптер является решением первоочередной задачи
обеспечения связи между реализацией объекта и брокером запросов. Для
организации взаимодействия между ORB и, например, системой управления
базами данных должен быть разработан свой объектный адаптер [10].
Скелетон – серверная программа, которая связывает сервант с объектным
адаптером, позволяя объектному адаптеру перенаправлять запросы к
соответствующему серванту. При статических методах вызова скелетон
формируется при компиляции IDL кода. При динамических – не
используется[12].
В структуре ORB выделяется Ядро, обеспечивающее внутреннее
представление объектов и передачу заявок, и набор надстраиваемых
компонентов, интерфейсы которых маскируют различия в реализации ORB.
Задачей Ядра является обеспечение мобильности программ и спецификаций
типов, а также достижение интероперабельности компонентов в распределенной
неоднородной среде. Клиенты максимально мобильны и должны работать без
изменения исходного кода в среде любого ORB, который поддерживает
отображение IDL в соответствующий язык программирования.
Языковое отображение включает определение характерных для IDL типов
данных и интерфейсов доступа к объектам средствами соответствующего языка
программирования. Отображение определяет структуру интерфейса стаба
клиента, интерфейса динамического вызова, скелетона реализации объекта,
объектных адаптеров и прямые интерфейсы ORB.
Для определенного языкового отображения обеспечивается программный
интерфейс к стабу для каждого типа интерфейса. Стабы осуществляют обращения
к ORB, используя скрытые и, возможно, оптимизированные для определенного
ядра ORB интерфейсы. Для определенного языкового отображения и, возможно, в
зависимости от используемого Объектного Адаптера будет обеспечиваться
доступ к методам, реализующим каждый объектный тип. Вызов этих методов
осуществляется через скелетон. Наличие скелетона не подразумевает
существование соответствующего стаба клиента. Возможно, и обратное. Можно
написать Объектный Адаптер, который не использует скелетоны для вызова
методов реализации объектов [10].
Доступно широкое множество способов реализации конкретных ORB-ов.
Далее будут приведены примеры таких реализаций. Следует иметь ввиду, что
конкретный ORB может быть реализован сразу несколькими способами.
ORB, включаемый в клиентское и серверное приложение.
Если имеется подходящий механизм коммуникаций, то возможна реализация
ORB-а в виде набора подпрограмм как со стороны клиента, так и со стороны
реализации объекта. Вызовы методов могут транслироваться в работу со
средствами взаимодействия процессов (Inter Process Communication - IPC).
ORB, выполненный в виде сервера.
С целью обеспечения централизованного сбора и управления всевозможной
информацией, ORB может быть реализован в виде отдельного приложения.
Взаимодействующие приложения устанавливают контакт с ORB-ом посредством
нормальных механизмов IPC.
ORB как часть системы.
Для повышения надежности, защиты данных и достижения лучшей
производительности ORB может быть реализован как часть операционной
системы. При этом ссылки на объект могут быть сделаны постоянными, таким
образом уменьшая время, необходимое для обработки каждого запроса. При
реализации ORB-а как части операционной системы возможны всевозможные виды
оптимизации, такие как избежание кодирования и декодирования данных, если
клиент и сервер находятся на одной и той же машине.
ORB, основанный на библиотеках.
Если код объекта занимает небольшой объем и не требует никаких
дополнительных средств, то он может быть выполнен в виде библиотеки. При
этом все заглушки на самом деле будут являться настоящими методами. При
этом предполагается, что, имея доступ к данным реализации, клиент не
разрушит эти данные.



2 Язык определения интерфейсов


Один из ключевых принципов архитектуры CORBA, обеспечивающий
интероперабельность приложений, заключается в независимости спецификации
интерфейсов объектов от их реализации. Именно для решения этой задачи в
комплексе стандартов CORBA предусматривается специальный язык для
определения интерфейсов - OMG IDL (Interface Definition Language).
Определение интерфейса объекта средствами OMG IDL полностью
характеризует все операции, которые могут выполняться данным объектом по
заявкам клиентов. Это определение служит источником информации для
разработки программ-клиентов, обращающихся к объектам с заявками на
выполнение операций, предусмотренных определениями их интерфейсов.
Поскольку определение используемого клиентом интерфейса должно быть
доступно его реализации, необходимо осуществлять отображение спецификаций,
заданных в языке OMG IDL, в язык реализации клиента.
Для описания синтаксиса языка в спецификациях стандарта CORBA используется
нотация, аналогичная EBNF (Extended Backus-Naur Format - Расширенный формат
Бэкуса-Наура).
::= - является по определению
| - или
< > - нетерминальный символ, представляемый заключенным в скобки понятием
"текст" - литерал
* - возможность повторения предшествующей синтаксической конструкции нуль
или более раз
+ - возможность повторения предшествующей синтаксической конструкции один
или более раз
{ } - заключенные в скобки синтаксические конструкции рассматриваются как
единая конструкция
[ ] - заключенная в скобки синтаксическая конструкция является
необязательной.
При отображении IDL в различные языки программирования CORBA требует,
чтобы конструкции IDL были адекватно отображены: все базовые и
конструируемые типы, ссылки на объекты и константы, определяемые в IDL,
вызовы операций, исключительные ситуации, доступ к атрибутам, сигнатуры
операций в виде, определенном ORB (интерфейс динамического вызова).
Реализация отображения дает возможность программисту иметь доступ ко всем
функциям ORB в виде, удобном для соответствующего языка программирования.
Все реализации ORB должны следовать стандарту OMG отображения для
конкретного языка программирования.
Основные вопросы, вызывающие трудности при разработке стандартов
отображения IDL, включают выбор представления объекта ORB в конкретном
языке программирования (следует различать, как объект представляется в
программе, как он передается в качестве параметра, как осуществляется вызов
операций на его интерфейсе); представление исключительных ситуаций в
конкретном языке; представление интерфейсов ORB.
К настоящему времени OMG определены отображения IDL в языки C, C++ и
Smalltalk. Завершается разработка стандарта отображения IDL в язык Ada. Эта
работа не проста. Так, только обсуждение и принятие отображения IDL в С++
заняло более двух лет напряженной работы, подтвердившей важность технологии
принятия стандартов, используемой OMG [10].



3 Сетевая модель CORBA


Интероперабельность брокеров поддерживается Универсальным
Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP
является универсальным, поскольку он не зависит от конкретной сетевой
транспортной среды и может быть отображен в любой транспортный протокол,
поддерживающий виртуальные соединения. Одно из таких отображений -
отображение GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве
Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно
IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать
сети брокеров в рамках Internet и за ее пределами.
Согласно GIOP, внутренняя архитектура брокеров предполагается
неизвестной. Подход, который может быть выбран конкретным брокером для
поддержки GIOP/IIOP, не определяется. Все, что требуется для согласованного
включения брокера в компьютерную сеть, - это существование связанных с ним
компонентов, способных посылать и принимать сообщения IIOP.
Спецификация GIOP включает:
1) определение Общего представления данных (Common Data
Representation - CDR), являющегося, по существу, коммуникационным
синтаксисом, отображающим значения типов данных OMG IDL в формат
передачи данных между брокерами и межброкерными мостами
(агентами);
2) форматы передаваемых между агентами сообщений GIOP, которые
введены для поддержки объектных заявок, установления
местоположения реализаций объектов и управления транспортными
соединениями;
3) определение ограничений на допустимый сетевой транспорт GIOP.
Протокол IIOP, который можно считать специализацией GIOP, определяет
дополнительно, как агенты открывают соединения TCP/IP и используют их для
передачи сообщений GIOP. GIOP трактует транспортное соединение как
асимметричное. Определяются две различных роли использования соединения:
роль клиента и роль сервера. Клиент образует соединение и посылает
объектные заявки, сервер принимает заявки и посылает ответы. Сервер не
может посылать объектных заявок. Соединение может использоваться совместно
многочисленными клиентами в одном брокере для посылки независимых заявок
различным объектам в определенном брокере или сервере. Допускается
асинхронная посылка заявок при их произвольном чередовании в соединении.
В передаваемых сообщениях допускается произвольный порядок байтов
(зависящий от архитектуры процессора), устанавливаемый отправителем
сообщения. Получатель сообщения должен изменить этот порядок нужным для
себя образом. Установлены выравнивания значений базовых типов IDL (char,
octet, short, unsigned short, long, unsigned long, float, double, boolean,
enum) по границе естественных для них полей. Установлено кодирование
конструируемых типов IDL (struct, union, array, sequence, string), не
накладывающее дополнительных требований выравнивания по отношению к тем,
которые установлены для базовых типов [9].


Объектная модель CORBA

Объектная модель OMG определяет общую объектную семантику для
спецификации базовых характеристик объектов стандартным, независимым от
реализации образом.
Объектная модель OMG определяется в виде объектной модели - ядра
(Core Object Model - COM) и совокупности расширений. Объектная модель -
ядро - специфицирует некоторый набор базовых понятий. Примерами понятий COM
являются объекты, операции, типы, отношение тип/подтип, наследование,
интерфейс типа. Каждое расширение вводит дополнительный набор понятий.
Расширяться может либо COM, либо уже существующие и согласованные
расширения. При этом вводится понятие профиля, как некоторой комбинации
COM, и одного или нескольких расширений, вместе поддерживающих определенную
целевую архитектуру [3].
Объектная модель CORBA определяет взаимодействие между клиентами и
серверами. Клиенты - это приложения, которые запрашивают сервисы,
предоставляемые серверами. Объекты-серверы содержат набор сервисов,
разделяемых между многими клиентами. Операция указывает запрашиваемый
сервис. Интерфейсы объектов описывают множество операций, которые могут
быть вызваны клиентами определенного объекта. Реализации объектов - это
приложения, исполняющие сервисы, запрашиваемые клиентами [10].


Клиенты и серверы CORBA

Клиентом является компонент, который обращается к интерфейсам других
компонентов. Компоненты, предоставляющие свои интерфейсы другим
компонентам, являются серверами.
В трехуровневой архитектуре понятие клиента и сервера весьма условно.
Компонент распределенной системы может выступать одновременно в роли
клиента для другого компонента и быть сервером для других компонентов
системы (рис. 2).



4 Стабы и скелетоны


Клиентские стабы (заглушки) и серверные скелетоны выступают в роли
«клея», который связывает языково-независимую спецификацию интерфейса на
IDL с языково-зависимым кодом реализации. Клиентские стабы каждого
интерфейса включаются клиентами, которые используют эти интерфейсы.
Клиентский стаб для конкретного интерфейса обеспечивает пустые реализации
для каждого метода этого интерфейса. Перед тем, как выполнить сервер
функциональности, стаб клиента соединяется с Брокером Объектных Заявок,
чтобы передать и получить параметры. Стаб клиента, который генерируется IDL-
компилятором, это часть кода, которая делает доступным клиенту интерфейс
конкретного CORBA сервера. Скелетон сервера, также генерируемый IDL-
компилятором, это часть кода, которая обеспечивает «каркас», на котором
построен код реализации сервера для конкретного интерфейса.


5 Основные объектные службы CORBA


Трехуровневая архитектура информационных систем, согласно
спецификациям OMG, включает в себя системы управления данными, сети
взаимодействующих CORBA-объектов и пользовательские интерфейсы для
представления данных.
Однако очевидно, что в большинстве ИС требуется некоторое множество
системных объектных сервисов, которые не зависят от предметной области и
обеспечивают базовую функциональность для управления распределенными
объектами. С целью облегчения создания распределенных приложений консорциум
OMG стандартизовал наиболее часто употребляемые сервисы (спецификация
CORBAservices 1.0) [10].
Сервис Жизненнго Цикла (Life Cycle Service) определяет операции создания,
копирования, перемещения и удаления компонентов на шине [7].
Сервис Именования (Naming service) служит для управления и хранения ссылок
на CORBA-объекты. Его основная задача состоит в том, чтобы универсальным
образом организовать соединение объектов друг с другом. Служба имен
представляет собой хранилище объектных ссылок. Обращение к этому сервису
выполняется для получения нужной объектной ссылки, идентифицируемой по
читаемому (понятному разработчику) имени объекта.
Сервис Событий (Event service) обеспечивает поддержку асинхронного
взаимодействия приложений.
Сервис Долговременного Хранения (Persistence service) предоставляет набор
универсальных интерфейсов для сохранения экземпляров объектов в
долговременной памяти. Сервис разработан таким образом, что возможна его
реализация на основе объектной базы данных.
Сервис Транзакций (Transaction service) поддерживает множество моделей
транзакций, включая вложенные транзакции. Сервис транзакций необходим для
корректной работы приложений в многопользовательском режиме.
Сервис Отношений (Relationship service) реализует логические связи между
CORBA-объектами. Сервис определяет два дополнительных типа объектов: связь
и роль. Роль представляет собой CORBA-объект, отражающий характер связи, а
связь характеризует зависимости объектов прикладной области.
Сервис Контроля Совместного Доступа (Concurrency control service) позволяет
клиентам координировать свои действия при использовании разделяемых
ресурсов. Управление разделяемыми ресурсами осуществляется с помощью
блокировок. Каждая блокировка ассоциируется с единственным ресурсом и
единственным клиентом. Сервис определяет также несколько режимов
блокировок, которые соответствуют различным способам доступа.
Сервис Внешнего Представления (Externalization service) формирует копию
CORBA-объекта в виде некоторого внешнего представления - файла, элемента
базы данных и т. д. [10].
Сервис Запросов (Query Sevice) обеспечивает поддержку запросов для
объектов. Он представляет собой надмножество SQL и основан на расширенных
спецификациях SQL3 и языке объектных запросов (Object Query Language -
OQL).
Сервис Лицензирования (Licensing Service) предоставляет операции для
отслеживания использования компонентов, чтобы обеспечить законную
компенсацию их использования. Данный сервис поддерживает некоторую модель
использования компонента в любой точке его жизненного цикла.
Сервис Свойств (Properties Service) предоставляет операции, которые
позволяют вам ассоциировать именованные величины (или свойства) с любым
компонентом.
Сервис Времени (Time Service) предоставляет интерфейс для синхронизации
времени в среде распределенных объектов. Кроме того, предусматривает
операции для определения и управления событиями, ориентированными на
определенное время.
Сервис Безопасности (Security Sercice) предоставляет полную инфраструктуру
для обеспечения безопасности распределенных объектов. Он поддерживает
аутентификацию, списки контроля доступа, конфиденциальность, безотказность
и делегирования прав доступа между объектами.
Сервис Коммерции (Trade Service) обеспечивает «Желтые страницы» для
объектов; это дает возможность объектам оповещать о своих сервисах и
выставлять заявки о себе на «рынок труда».
Сервис Контейнеров (Collection Service) предоставляет интерфейсы CORBA для
создания и поддержки общедоступных контейнеров [7].

Известно, что службы OMG не являются независимыми друг от друга.
Часть из них может быть создана на базе других служб. Согласно
рекомендациям OMG, существует представленный на рис. 3 граф зависимостей
одной службы от другой [11].

6 Универсальные средства CORBA


Универсальные средства предоставляют поддержку интерфейсов высокого
уровня и делятся на два типа: горизонтальные и вертикальные.
Горизонтальные универсальные средства определяют интерфейсы, не
зависящие от предметной области. В настоящее время существует
предварительная спецификация горизонтальных универсальных средств,
состоящая из следующих разделов:
1) Средств пользовательского интерфейса. Они покрывают аспекты, касающиеся
представления информации, и включают инструменты для разработки
интерфейса, средства для автоматизации этой работы, спецификации на
рабочий стол (desktop) пользователя и т. д.
2) Средств управления информацией. Они предоставляют операции, с помощью
которых можно моделировать, описывать, сохранять, выбирать, перемещать
информацию и обмениваться ею. Предполагается, что данный набор должен
состоять из следующих спецификаций:
а) информационное моделирование (определяет правила, по которым
осуществляется структуризация и доступ к информации),
б) хранение и выборка информации (определяет использование баз данных
и систем каталогов),
в) информационный обмен,
г) стандарты перекодировки и представления, поддерживающие обмен
информацией через разделяемые ресурсы, сетевые протоколы или
программные интерфейсы.
3) Средств управления системой. Они задают множество утилит, реализующих
функции системного администрирования, то есть определяют интерфейсы
основных операций, отвечающих за управление, мониторинг, безопасность,
конфигурирование и т. д.
4) Средств управления задачами. Предполагается, что данный набор будет
представлен четырьмя спецификациями: службы управления потоками работ
(workflow facility), службы программных агентов (agent facility), службы
управления правилами (rule management facility), службы автоматизации
(automation facility).
Вертикальные средства предназначены для поддержки конкретных областей
рынка: финансовой деятельности, промышленного производства, медицины и т.
д. Разрабатываются спецификации следующих средств:
1) Средств обработки изображений. Специфицируют доступ и обмен графическими
данными. Роль этой службы заключается в поддержке приложений конечного
пользователя по проверке, обработке, визуализации и сохранению
графических данных.
2) Средств поддержки информационной супермагистрали (superhighway
facility). Специфицируется множество сетей, протоколов и правил их
использования, а также множество репозитариев информации и набор
средств, обеспечивающих пользователям и приложениям доступ к этой
информации.
3) Средств интегрированного автоматизированного производства. Обеспечивают
интеграцию производственных функций предприятия с помощью компьютеров. В
число объединяемых функций могут входить также управление процессами
разработки, контроль качества, финансовые и маркетинговые операции.
4) Средств эмуляции распределенных процессов. Службы этой спецификации
должны обеспечить базис, на основе которого возможно быстрое построение
и функционирование эмулируемой модели.
5) Средств информатизации в газовой и нефтяной промышленности. Эта
предметная область характеризуется большим количеством данных и высокой
сложностью алгоритмов.
6) Средств финансовых коммуникаций (accounting facility). Включают все
формы коммерческих транзакций: обмен валюты, управление платежами,
продажами и т.п.
7) Средств поддержки разработки приложений. Обслуживают выбор, разработку,
построение и эволюцию приложений, составляющих корпоративную
информационную систему. Данные спецификации включают средства анализа,
проектирования, реализации, тестирования и поддержки системы [10].



7 Заключение


В разделе дан обзор информационной архитектуры систем на основе
объектной технологии и принципов интероперабельности компонентов,
развиваемых OMG.
Нетрудно видеть, что архитектура CORBA специально ориентирована на
достижение целей - насущных потребностей разработки прикладных систем,
сформулированных в начале статьи:
1) обеспечение функционирования систем в условиях информационной и
реализационной неоднородности, распределенности и автономности
информационных ресурсов;
2) интеграция систем;
3) реинженерия систем;
4) миграция унаследованных систем;
5) повторное использование неоднородных информационных ресурсов;
6) продление жизненного цикла систем.
Объектный подход развивается около 25 лет. За это время он прошел
путь от академических исследований до промышленных, стандартизованных
решений, позволяющих создавать по-настоящему большие, распределенные
корпоративные системы, способные эволюционировать экономически эффективным
образом. Можно предположить, что консолидация современных сетевых,
реляционных и объектно-ориентированных технологий позволит выйти на еще
более высокий уровень интеграции и качества информационных систем.
Рассматриваемая архитектура убедительно показывает, что время объектных
технологий, технологий конца 20 - начала 21 века, пришло.
Список использованных источников

Аншина М. Симфония CORBA. «Открытые системы» №3 1998 г.

Ахтырченко К. В., Леонтьев В. В. Распределенные объектные технологии в
информационных системах. «СУБД» №5-6 1997 г.

Брюхов Д.О, Задорожный В.И, Калиниченко Л.А, Курошев М.Ю, Шумилов С.С
Интероперабельные информационные системы: архитектуры и технологии. «СУБД»
№4 1995 г.

Елманова Н. Распределенные вычисления и технологии Inprise. «Комьютер-
Пресс» №1-5 1999 г.

Елманова Н. Оптимизация приложений С++Builder в архитектуре клиент/сервер.
«Компьютер-Пресс» №4 1998 г.

Коржов В. Многоуровневые системы клиент-сервер. «Сети» №6 1997 г.

Орфали Р., Харкин Д., Эдвардс Д. Основы CORBA: Пер. с англ. – М.: МАЛИП,
Горячая Линия – Телеком, 1999 г.

Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения
интерфейсов IDL в архитектуре CORBA. «СУБД» №2 1996 г.

Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте
CORBA 2.0. «СУБД» №3 1996 г.

Пуха Ю. Объектные технологии построения распределенных информационных
систем. «СУБД» №3 1997 г.

Ахтырченко К. В. Применение технологии CORBA при построении распределенных
информационных систем. «СУБД» №1, №2 1998г.

Аншина М. Увлекательное путешествие с CORBA 3: по широким просторам
распределенных приложений. «СУБД» №5, №6 1999г.

-----------------------
Рис. 3


Граф зависимостей служб, специфицированных OMG

Рис. 2


Структура интерфейсов Брокера Объектных Заявок

Рис. 1


Отношения между компонентами в
трехуровневой распределенной системе






Реферат на тему: Обзор х86 процессоров

Институт Переподготовки Кадров
Уральского Государственного Технического Университета


Кафедра микропроцессорной техники



Оценка работы



Члены комиссии



ОБЗОР ПРОЦЕССОРОВ I80X86



Курсовая работа


Пояснительная записка



Руководитель
к.т.н. доцент И. Е. Мясников



Слушатель
Группа СП-913 А. А. Соколов



ЕКАТЕРИНБУРГ
1997



СОДЕРЖАНИЕ


ПОСТАНОВКА ЗАДАЧИ ………………………………………………………………………………………… -
СОДЕРЖАНИЕ …………………………………………………………………………………………………………… 3
ВВЕДЕНИЕ ………………………………………………………………………………………………………………… 4
1. КРАТКИЙ ОБЗОР ПРОЦЕССОРОВ ФИРМЫ INTEL …………………………… 5
1 ПРОЦЕССОР i8086 ……………………………………………………………………………… 4
2 ПРОЦЕССОР i8088 ……………………………………………………………………………… 6
3 ПРОЦЕССОР i80286 …………………………………………………………………………… 8
4 ПРОЦЕССОР i80386 …………………………………………………………………………… 10
2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ i80286 ……………………………………………… 11
2.1 Режим реальной адресации ……………………………………………………… 12
2.2 Режим защиты …………………………………………………………………………………… 13
2.3 Сопроцессор i80287 ……………………………………………………………………… 14
2.3.1 Условия программирования i80287 ……………………… 15
3. Основные характеристики i80386 ……………………………………………… 16
3.1 32-битная архитектура ……………………………………………………………… 17
3.2 Высокопроизводительная технология ……………………………… 18
3.3 Обеспечение работы с виртуальной памятью …………… 20
3.4 Механизмы защиты……………………………………………………………………………… 21
3.5 Совместимость с микропроцессорами 8086/80286…… 22
3.6 Способы адресации…………………………………………………………………………… 23
3.7 Главные типы данных……………………………………………………………………… 24
3.7.1 Типы данных математического сопроцессора… 25
заключение …………………………………………………………………………………………………………… 26
БИБЛИОГРАФИЧЕСКИЙ СПИСОК………………………………………………………………………… 27



ВВЕДЕНИЕ

Процессоры фирмы INTEL являются не самым лучшим решением для
персональных компьютеров, но благодаря тому, что i80х86 наследуют все
свойства предыдущих моделей - они получили самое широкое распространение в
мире. Наряду с INTEL аналогичные процессоры выпускают и другие фирмы - AMD,
Texas Instruments, Cyrix, NexGen, Motorola и другие. Многие из них
отличаются не только количеством элементов на кристалле, но и системой
команд, архитектурой.



1. КРАТКИЙ ОБЗОР ПРОЦЕССОРОВ ФИРМЫ INTEL

1.1 ПРОЦЕССОР i8086

В 1976 году фирма Intel начала усиленно работать над
микропроцессором i8086. Размер его регистров был увеличен в два раза, что
дало возможность увеличить производительность в 10 раз по сравнению с 8080.
Кроме того, размер информационных шин был увеличен до 16 разрядов, что
дало возможность увеличить скорость передачи информации на микропроцессор и
с него в два раза. Размер его адресной шины также был существенно увеличен
- до 20 бит. Это позволило 86-му прямо контролировать 1М оперативной
памяти. Как прямой потомок i8080, i8086 унаследовал большую часть множества
его команд. Регистры этого процессора были разработаны таким образом, что
они могли обрабатывать как 16-ти битные значения, так и 8-ми битные - также
как это делал i8080. Память i8086 была также доработана специальным
образом. Весь мегабайт оперативной памяти не представлялся единым полем,
а был разделен на 16 сегментов величиной по 64К. Таким образом, память 8086
можно было представить, как объединенную вместе память нескольких i8080.
i8086 работал с каждым сегментом по отдельности, не позволяя большим
информационным структурам переходить через границы сегментов. В некотором
смысле i8086 опередил свое время. Малые компьютеры основывались на 8-ми
битной архитектуре, память была очень дорога, требовались дополнительные
16-ти битные микросхемы. Использование этого процессора предполагалось в 16-
ти битных устройствах, которые не оправдывали свою цену в то время.



1.2 ПРОЦЕССОР i8088

Через год после презентации 8086, Intel объявил о разработке
микропроцессора i8088. Он являлся очень похожим на i8086:
16-битные регистры, 20 адресных линий, тот же набор команд - все то же, за
исключением одного, - шина данных была уменьшена до 8 бит. Это позволяло
полностью использовать широко распространенные в то время 8-битные элементы
технического обеспечения.
Как шаг назад в истории разработки микропроцессоров i8088 мог
потеряться в истории, как это было с i8085, не реши IBM реализовать свой
первый персональный компьютер на его базе. Выбор IBM был объясним. Восьми
битная шина данных позволяла использовать имеющиеся на рынке микросхемы.
Шестнадцати битная внутренняя структура давала
важные преимущества по сравнению с существующими микропроцессорами. Как
приемник 80-го микропроцессора, i8088 мог понимать незначительно
доработанные программы, работающие с CP/M. По большому счету, все эти
преимущества были временными, а в некоторых случаях и иллюзорными. Но
восьми битный чип был еще и не дорогим. Последнее явилось более важным
аргументом, чем 16-битные регистры и легко адаптируемые программы CP/M.
Итак, i8088 явился базой для разработки семейства
малых компьютеров. Он подготовил почву для быстрого создания совместимых
настольных компьютеров.
Потенциально 8086 был в два раза производительней, и почти полностью
совместим с i8088. Микропроцессоры i8088 и i8086 совместимы, но не
взаимозаменяемы. Восемь дополнительных бит данных требовали 8-ми
дополнительных проводов. Таким образом подключение этих двух микросхем было
различным. Компьютер разрабатывался либо под один микропроцессор, либо под
другой.
Вот некоторые выдержки из технического описания IBM PC XT:
Сердцем системной платы является микропроцессор Intel 8088. Этот процессор
представляет собой версию 16 - битного процессора Intel 8086 с 8-битным
выходом на внешнюю магистраль и является программно совместимым с
процессором 8086. Таким образом, 8088 поддерживает 16-битные операции,
включая умножение и деление, и поддерживает 20-битную адресацию (до 1
Мбайта памяти). Он также работает в максимальном режиме. Поэтому в
систему может быть добавлен сопроцессор. Процессор работает с тактовой
частотой 4.77 МГц. Эта частота, которая получается из частоты
кварцевого генератора
14.31818 МГц, делится на 3 тактовым генератором процессора и на 4 для
получения сигнала цветности 3.58 МГц, необходимого для цветного
телевидения. При тактовой частоте 4.77МГц цикл обмена по магистрали
8088 составляет четыре периода по 210 нс. или 840 нс. Цикл вода/вывода
требует пяти тактов по 210 нс. и составляет 1.05 мкс.
Процессор поддерживается набором многофункциональных устройств обеспечивая
четыре канала 20-битного прямого доступа к памяти, три 16-битных канала
таймеров-счетчиков и восемь приоритетных уровней прерывания...
ЦП 8088 компьютера IBM PC производит выборку команды по адресу,
интерпретирует ее, выполняет действие, требуемое этой командой, (например,
сложение двух чисел), затем переходит к выполнению следующей команды. Если
следующая команда не направит процессор 8088 непосредственно к
определенной ячейке памяти, чтобы выполнить записанную там команду,
процессор будет двигаться от одной команды к другой по ячейкам памяти,
расположенным последовательно (шаг за шагом). Наиболее существенная разница
между пошаговым выполнением программы (последовательности команд) и
пошаговой работой компьютера заключается в том, что компьютер IBM может
выполнять около миллиона таких шагов в секунду...
По мере того, как появились микропроцессоры, состоящие из многих
тысяч дискретных элементов, появилась возможность реализации дополнительных
функций в рамках одной микросхемы. При разработке компьютера, помимо
микропроцессора, используются и другие дополнительные устройства:
контроллеры прерываний, таймеры и контроллеры шин. Функции этих устройств
технически можно реализовать в одном корпусе с микропроцессором.
Однако эти возможности никогда не реализуются на практике. Микропроцессор,
как и все дополнительные устройства, может использоваться не только в
компьютерах.
По мере развития компьютерной индустрии, рынком была проведена
оптимизация разделения функций между устройствами. И каждое устройство
развивалось в направлении реализации своих функций. Intel продолжал
совершенствовать свои микропроцессоры. В 1982 году был представлен
микропроцессор i80186. Этот чип стал базовым для создания целого ряда
совместимых компьютеров и реализации турборежима. Так же был создан
микропроцессор i80188 - приемник i8088.



1.3 ПРОЦЕССОР i80286

Презентация IBM персонального компьютера AT в 1984 году сфокусировала
все внимание на другой микропроцессор - i80286. Сам по себе микропроцессор
был представлен еще в 1982 году. Естественно у 8086 и 80286 много общего,
но i80286 обладает такими дополнительными качествами, которые сразу
привлекли пристальное внимание всех связанных с компьютерной индустрией.
Новый микропроцессор использует
полную 16-разрядную шину данных и 16-битные внутренние регистры. Он был
разработан для работы с частотой в 6 Мгц, а затем 8 и 10 Мгц. Более того,
i80286 способен реализовывать свои функции быстрее, чем это следует из
простого роста частоты.
В конечном счете, самым большим преимуществом i80286 было то, что он
имел способность работать с дополнительной памятью. Вместо 20-разрядной
адресной шины i8088/i8086, i80286 имел 24-разрядную шину. Эти
дополнительные 4 разряда давали возможность увеличить максимум адресуемой
памяти до 16 М.
i80286 позволил также использовать виртуальную память. Название
говорит само за себя, что виртуальная память организуется не на каких-то
отдельных физических чипах. Более того, информация хранится где-то во
внешней памяти, но система обеспечивает к ней прямой доступ. i80286 снабжен
специальными средствами, которые дают ему возможность отличать, к реальной
или виртуальной памяти относится
любой байт. Эти средства реализуются дополнительными схемами, включенными в
микропроцессор. Они дают возможность работать с 1Г памяти, включающую в
себя 16М физической памяти и 1008М виртуальной.
Теоретически i80286 должен был преодолеть барьер адресуемой памяти в
1М, который был установлен предыдущими моделями. Но в действительности эта
возможность не была реализована.
Проблема была частично в традициях, а частично в совместимости. Ко
времени появления i80286 IBM PC имела гарантированный успех. Для i8088,
i8086 было разработано огромное программное обеспечение. Отказ от
использования этих разработанных программ ставил под сомнение использование
нового чипа. Для обеспечения совместимости с ранее разработанными чипами
разработчики i80286 обеспечили его работу в двух режимах: в реальном и
защищенном. Реальный режим был скопирован с режима работы i8086. Причем
разработчики работали так добросовестно, что внесли в реальный режим и
ограничение по использованию только 1М памяти.
Чтобы использовать улучшенные возможности Intel 80286, фирма
разработала защищенный режим. Хотя отсутствовала программная совместимость
с i8086, этот режим позволял использовать все 16М и даже 1Г виртуальной
памяти в программах, работающих в защищенном режиме.
Точно так же как и i8086 в свое время, i80286 давал такие огромные
ресурсы памяти, потребность в которых ещё не назрела к тому времени.
Поэтому этот режим не сразу был признан широким кругом пользователей.
Потребовалось почти три года, прошедших с момента презентации первой АТ и
появлением операционной системы OS/2, работающей в этом режиме, и
ознаменовавшей собой начало его широкого применения.
Имелись две причины медленной популяризации защищенного режима. Для
программистов, работающих в DOS, существенным являлся вопрос перехода
между реальным и защищенными режимами. Intel разработал переход между
режимами только в одном направлении. Микропроцессор начинал работу только
в реальном режиме, когда происходило тестирование всех 16М памяти, но для
использования этого ресурса необходимо было перейти в защищенный режим.
Иначе пользователь мог довольствоваться только 1М памяти. Обратного
перехода от защищенного режима к реальному не существует - требуется
перезагрузка.
Кроме того, защищенный режим реализовывал только частично чаяния
программистов. Вся огромная память i80286 была разделена на сегменты по
64К. Вместо того чтобы свободно использовать весь ресурс памяти,
программистам приходилось мудрствовать, чтобы преодолеть эти барьеры между
сегментами.



1.4 ПРОЦЕССОР i80386

i80386 был создан в 1985 году. i80386 был создан при полной
ясности всех требований, предъявляемых к микропроцессорам и компьютерам.
i80386 имел все положительные качества своих предшественников. Все
микрокоды i80286 входили во множество микрокоманд i80386. Поэтому старое
программное обеспечение могло использоваться с i80386. Но вместе с тем у
i80386 были дополнительные возможности. Особенно привлекала возможность
работать без ограничения связанного с сегментацией памяти. Размеры
регистров и шины данных были увеличены до 32 бит. Информация передавалась
и обрабатывалась в два раза быстрее, чем у 16-битного i80286.
С самого начала разработчики 80386 ставили перед собой задачу создать
быстрый чип. При его создании использовалась CHMOS технология. Первые
i80386 начали работать с наивысшей частотой, достигнутой для i80286. Затем
появилась 20 Мгц модель. В 1985 году предел был отодвинут до 25 Мгц. А
вскоре и до 33 Мгц.
С увеличением шины данных до 32 бит, число адресных линий также
было увеличено до 32. Само по себе это расширение позволило
микропроцессору прямо обращаться к 4Гб физической памяти. Кроме того, он
мог работать с 16 триллионами байт виртуальной памяти. Микропроцессор имел
все необходимое для реализации последнего. Огромное преимущество давал
способ организации памяти i80386. К ней можно было обращаться, как к одному
большому полю, доступному для программ. То есть структуры данных и
программы могли быть объемом в целую память. Разделение памяти на
сегменты возможно, но не обязательно. Сегменты могут быть произвольны, а не
ограничены по64К.
Кроме того, i80386 снабжен 16 байтами кэш-памяти. Это специально
встроенное поле памяти используется для хранения нескольких команд
микропроцессора. Независимо от производимых микропроцессором расчетов,
специальная схема загружает в эту память код программного обеспечения,
прежде чем в нем появится необходимость. Эта небольшая кэш-память помогает
процессору работать более проворно без задержек, связанных с ожиданием
загрузки очередной команды из оперативной памяти.
Для того чтобы обеспечить совместимость с предыдущими микропроцессорами и
с огромной библиотекой DOS-программ i80386 был разработан таким образом,
чтобы быть, как можно больше похожим на i8086 и i80286. Как и его
предшественники, i80386 позволял работать в защищенном режиме с
ограничением адресуемой памяти в 1М. В этом режиме он загружал и выполнял
все программы, разработанные на процессорах предшествующих поколений.
С реального режима i80386 мог быть переведён в защищенный режим, где
он функционировал подобно 80286, за исключением объёма памяти. В этом
режиме в распоряжении программиста было больше памяти, и он мог более гибко
манипулировать ею, потому что мог изменять размеры сегмента.
В противоположность i80286 - i80386 мог переходить из одного режима
в другой без перезагрузки машины, а посредством команд программного
обеспечения.
Новый режим, названный виртуальным режимом 8086 (Virtual mode), давал
i80386 особенно большие свободы по использованию многозадачных ОС. В этом
режиме этот процессор работал не как один 8086, а как неограниченное их
количество в одно и тоже время. Этот режим позволял процессору разбивать
память на множество виртуальных машин, каждая из которых работала так, как
будто она была отдельным компьютером на 8086 чипе.



2. ОСНОВНЫЕ ХАРАКТЕРИСТИКИ i80286


Микропроцессор i80286 предусматривает 24-разрядную адресацию, 16-
разрядный интерфейс памяти, расширенный набор команд, функции ПДП и
прерываний, аппаратное умножение и деление чисел с плавающей запятой,
объединенное управление памятью, 4-уровневую защиту памяти, виртуальное
адресное пространство на 1 гигабайт (1 073 741 824 байта) для каждой задачи
и два режима
работы: режим реальной адресации, совместимый с микропроцессором i8086, и
режим защищенной виртуальной адресации.



2.1 Режим реальной адресации

В режиме реальной адресации физическая память микропроцессора
представляет собой непрерывный массив объемом до одного мегабайта.
Микропроцессор обращается к памяти, генерируя 20-разрядные физические
адреса. 20-разрядный адрес сегмента памяти состоит из двух частей: старшей
16-разрядной переменной части и младшей 4-разрядной части, которая всегда
равна нулю. Таким образом, адреса сегментов всегда начинаются с числа,
кратного 16. В режиме реальной адресации каждый сегмент памяти имеет
размер 64 Кбайта и может быть считан, записан или изменен. Если операнды
данных или команд попытаются выполнить циклический возврат к концу
сегмента, может произойти прерывание или возникнуть исключительная
ситуация; например, если младший байт слова смещен на FFFF, а старший байт
равен 0000. Если в режиме реальной адресации информация, содержащаяся в
сегменте, не использует все 64 КБайт, неиспользуемое пространство может
быть предоставлено другому сегменту в целях экономии физической памяти.



2.2 Режим защиты

Режим защиты предусматривает расширенное адресное пространство
физической и виртуальной памяти, механизмы защиты памяти, новые операции по
поддержке операционных систем и виртуальной памяти. Режим защиты
обеспечивает виртуальное адресное пространство на 1 гигабайт для каждой
задачи в физическом адресном пространстве на 16 Мегабайт. Виртуальное
пространство может быть больше физического, т.к. любое использование
адреса, который не распределен в физической памяти, вызывает возникновение
исключительной ситуации, требующей перезапуска.
Как и режим реальной адресации, режим защиты использует 32-разрядные
указатели, состоящие из 16-разрядного искателя и компонентов смещения.
Искатель, однако, определяет индекс в резидентной таблице памяти, а не
старшие 16 разрядов адреса реальной памяти. 24-разрядный базовый адрес
желаемого сегмента памяти получают из таблиц памяти. Для получения
физического адреса к базовому адресу сегмента добавляется 16-разрядное
смещение. Микропроцессор автоматически обращается к таблицам, когда в
регистр сегмента загружается искатель. Все команды, выполняющие загрузку
регистра, обращаются к таблицам памяти без дополнительной программной
поддержки. Таблицы памяти содержат 8-байтовые значения, называемые
описателями.



2.3 Сопроцессор i80287


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

- двоичные целые числа (3 типа);

- десятичные целые числа (1 тип);

- действительные числа (3 типа).



2.3.1 Условия программирования i80287

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

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


ТИПЫ ДАННЫХ


| Тип данных |Число |Число верных значащих |
| |битов |цифр |
|Целое слово | 16 | 4|
|Короткое целое | 32 | 9|
|Длинное целое | 64 | |
| | |19 |
|Упакованное десятичное | 80 | |
|короткое | |18 |
|Действительное длинное | 32 | |
| | |6-7 |
|Действительное | 64 | |
|временное | |15-16 |
|Действительное | 80 | |
| | |19 |



3. Основные характеристики i80386

Микропроцессор 80386 дает разработчику систем большое
число новых и эффективных возможностей, включая производительность от 3 до
4 миллионов операций в секунду, полную 32-битную архитектуру, 4 гигабитное
(2 байт) физическое адресное пространство и внутреннее обеспечение работы
со страничной виртуальной памятью.
Несмотря на введение в него последних достижений микропроцессорной
техники, 80386 сохраняет совместимость по объектному коду с программным
обеспечением, в большом количестве
написанным для его предшественников, 8086 и 80286. Особый интерес
представляет такое свойство 80386, как виртуальная машина, которое
позволяет 80386 переключаться в выполнении программ, управляемых
различными операционными системами, например, UNIX и MS-DOS. Это свойство
позволяет производителям оригинальных систем непосредственно вводить
прикладное программное обеспечение для 16-битных машин в системе на базе 32-
битных микропроцессоров.
Объединяя в себе производительность супермини ЭВМ и низкую стоимость
и функциональную гибкость микропроцессора, 80386 может открыть новые
рынки для микропроцессорных систем.
Применения, недопустимые прежде из-за невысокого быстродействия
микропроцессоров или не экономности использования супермини ЭВМ, стали
теперь практически осуществимы благодаря 80386. Такие новейшие
применения, как машинное зрение, распознавание речи, интеллектуальные
работы и экспертные системы, бывшие до недавнего времени в основном на
стадии эксперемента, теперь могут быть предложены на рынке.
Для тго, чтобы удовлетворить требованиям будущих применений, мало
иметь 32-битные регистры, команды и шины. Эти основные свойства являются
лишь отправной точкой для 80386.



3.1 32-битная архитектура

32-битная архитектура 80386 обеспечивает программные ресурсы,
необходимые для поддержки "больших " систем, характеризуемых операциями с
большими числами, большими структурами данных, большими программами (или
большим числом программ) и т.п. Физическое адресное пространство 80386
состоит из 2 байт или 4 гбайт; его логическое адресное пространство состоит
из 2 байт или 64 терабайт (тбайт). Восемь 32-битных общих регистров 80386
могут быть взаимозаменяемо использованы как операнды команд и как
переменные различных способов адресации.
Типы данных включают в себя 8-, 16- или 32-битные целые и порядковые,
упакованные и неупакованные десятичные, указатели, строки бит, байтов,
слов и двойных слов. Микропроцессор 80386
имеет полную систему команд для операций над этими типами
данных, а также для управления выполнением программ. Способы
адресации 80386 обеспечивают эффективный доступ к элементам
стандартных структур данных: массивов, записей, массивов записей и
записей, содержащих массивы.



3.2 Высокопроизводительная технология

32-битная архитектура не гарантирует высокой производительности.
Реализация потенциала архитектуры требует новейшей микроэлектронной
технологии, точного разделения функций и внимания к внешним операциям
кристалла, в особенности к взаимодействию процессора с памятью. Включение
этих свойств обеспечивает 80386 самую высокую произвидительность по
сравнению с любым другим существующим микропроцессором.
Микропроцессор 80386 реализован с помощью технологии фирмы Intel CH
MOSIII - технологического процесса, объединяющего в себе возможности
высокого быстродействия технологии HMOS с малым потреблением технологии
кмоп. Использование геометрии 1,5 мкм и слоев металлизации дает 80386 более
275000 транзисторов на кристаллле.
Микропроцессор 80386 разделен внутри на 6 автономно и
параллельно работающих блоков с соответствующей синхронизацией. Все
внутренние шины, соединяющие эти блоки, имеют разрядность 32 бит.
Конвейерная организация функциональных блоков в 80386 допускает временное
наложение выполнения различных стадий команды и позволяет одновременно
выполнять несколько операций. Кроме конвейерной обработки всех команд, в
80386 выполнение ряда важных операций осуществляется специальными
аппаратными узлами. Блок умножения/деления 80386 может выпонять 32-битное
умножение за 9-41 такт синхронизации, в зависимости от числа значащих цифр;
он может разделить 32-битные операнды за 38 тактов (в случае чисел без
знаков) или за 43 такта (в случае чисел со знаками). Регистр группового
сдвига 80386 может за один такт сдвигать от 1 до 64 бит.
Во многих 32-битных применениях, в таких как, например,
перепрограммируемые ЭВМ коллективного пользования, требуется
преобразование логических адресов в физические и защита памяти с помощью
блока управления памятью, БУП. В других применениях, например, в системах
управления в реальном времени, это не требуется. Для большинства
микропроцессорных систем с 32-битной архитектурой такое разделение
функций реализуется путем использования дополнительного корпуса блока
управления памятью. В отличие от них буп 80386 входит в состав процессора,
как один из двух функциональных блоков конвейерной структуры. Операционная
система, управляющая работой БУП, позволяет, например, системе реального
времени обходить страничное преобразование. Введение управления памятью
внутрь кристалла дает повышенную производительность в системах,
использующих БУП и не приводит к ее снижению в тех систмах, которые БУП не
используют. Такие характеристики стали возможны благодаря
снижению задержек распространения, использованию внутреннего
полупериодного тактирования и параллельной работы.
Еще одно свойство, необходимое в одних применениях и не
требующееся в других, это обработка больших чисел, в особенности в
арифметических операциях с плавающей запятой с одинарной и двойной
точностью. Операнды с плавающей запятой имеют большую длину, а необходимый
набор команд для операций над ними является довольно сложным; для
реализации стандартного набора операций с плавающей запятой в соответствии
со стандартом IEEE754 требуется несколько тысяч транзисторов. В этих целях
в 80386 имеется аппаратное обеспечение совместной работы с отдельным
математическим сопроцессором. К 80386 может быть подключен
математический сопроцессор либо 80287, либо более производительный 80387.
Для прикладного программного обеспечения сопроцессоры прозрачны; они
лишь расширяют архитектуру 80386 с помощью регистров, типов данных и
операций, требуемых стандартом IEEE754. Комбинация 80386 и 80387 может
исполнять 1,8 миллион операций.
32-битный процессор, работающий с частотой 16 мгц, имеет
большее быстродействие, чем большинство быстродействующих памятей,
вследствии чего его производительность может быть ограничена временами
доступа к памяти. 80386 был спроектирован так, чтобы с максимальной
эффективностью использовать как наиболее быстродействующие статистические
ОЗУ, так и недорогие динамические ОЗУ. Для обращения к быстрой памяти,
например типа кэш, 80386 вырабатывает двухтактный магистральный цикл для
адреса/данных. (Памяти типа кэш 80386 могут иметь любой объем от
минимального полезного 4 кбайт до максимального, охватывающего все
физическое адресное пространство). Обращение к более медленной памяти (или
к устройствам ввода/вывода) может производиться с использованием
конвейерного формирования адреса для увеличения времени установки данных
после адреса до 3 тактов при сохранении двухтактных циклов в процессоре.
Вследствие внутреннего конвейерного форморования адреса при исполнении
команды, 80386, как правило, вычисляет адрес и определяет следующий
магистральный цикл во время текущего магистрального цикла. Узел
конвейерного формирования адреса передает эту опережающую информацию в
подсистему памяти, позволяя, тем самым, одному банку памяти дешифрировать
следующий магистральный цикл, в то время как другой банк реагирует на
текущий магистральный цикл.



3.3 Обеспечение работы с виртуальной памятью

Виртуальная память позволяет ставить максимальный объем программы или
группы программ в зависимость от имеющегося адресного пространства на
диске, а не от объема физической памяти (ОЗУ), которая в настоящее время
приблизительно в 400 раз дороже. Из вытекающей отсюда гибкости
выигрывают изготовители оборудования (которые могут поставлять изделия,
отличающиеся лишь в конфигурациях памяти и в уровне производительности),
программисты (которые могут предоставлять управление хранением программ
операционным системам и избегать написания программ с перекрывающимися
структурами) и конечные пользователи (которые могут вводить новые и
большие по объему прикладные программы, не опасаясь нехватки памяти).
Виртуальная память реализуется операционной системой с
соответствующей аппаратурной поддержкой. Микропроцессор 80386
обеспечивает работу с системами виртуальной памяти с сегментной или
страничной организацией. Сегментная виртуальная память больше подходит для
небольших 16-битных систем, в которых объем сегмента не превышает 64
кбайт. 80386 обеспечивает работу с сегментами объемом до 4 гбайт; поэтому в
большинстве больших систем на базе 80386 системы виртуальной памяти будут
использовать возможность страничного запроса. Для каждой страницы
80386 вырабатывает биты присутствия, занятости или регистрации обращения,
которые необходимы для эффективной реализации виртуальной памяти со
страничными запросами. В случае обращения к несуществующей странице
80386 автоматически делает переход к операционной системе, если
операционная система считала с диска отсутствующую страницу, 80386
выполняет команду повторно. Высокая производительность в работе с
виртуальной памятью обеспечивается в 80386 использованием внутренней кэш-
памяти для хранения страничной информации. Эта кэш-память (называемая
буфером просмотра трансляции, TLB) содержит информацию

Новинки рефератов ::

Реферат: Конфигурирования программного обеспечения алгоритма OSPF на маршрутизаторе (Программирование)


Реферат: Интелегенция и революция (История)


Реферат: Общая характеристика этики образования – этические требования к учителю (Педагогика)


Реферат: Химико-токсикологический анализ производных фенотиазина (Химия)


Реферат: Коленчатый вал (Металлургия)


Реферат: Доказательства в гражданском процессе (Гражданское право и процесс)


Реферат: Бухгалтерский учет в бюджетных учреждениях (Бухгалтерский учет)


Реферат: Управление инновационными проектами (Менеджмент)


Реферат: Презумпция невиновности и ее значение в доказывании (Уголовное право и процесс)


Реферат: Майкельсон Альберт Абрахам (Физика)


Реферат: Власть и насилие (Государство и право)


Реферат: Покупка и продажа ценных бумаг гражданами (Финансы)


Реферат: Проблемы возникновения жизни и эволюции ее форм (Естествознание)


Реферат: Кометы Космическая опасность (Астрономия)


Реферат: Учет и аудит расчетов по товарным операциям (Бухгалтерский учет)


Реферат: Тесты. Тесты по выявлению личностных диспозиций (Социология)


Реферат: Алгоритм создания базы данных складского учета (Компьютеры)


Реферат: Глобализационные процессы в современном мире (Философия)


Реферат: Астана (История)


Реферат: Конспект лекций по дисциплине "Метрология и стандартизация". Часть 1. Метрология (Технология)



Copyright © GeoRUS, Геологические сайты альтруист