Литмир - Электронная Библиотека
Содержание  
A
A
ADDNS1143Короткая
ADDNR1243С округлением
ADDNSR1243Короткая с округлением
ADDNI1843Индикаторная
ADDNIS1943Индикаторная короткая
ADDNIR1A43Индикаторная с округлением
ADDNISR1B43Идикаторная короткая с округлением
ADDNB1C43С переходом
ADDNBS1D43Короткая с переходом
ADDNBR1E43С оКороткая с округлением и с пере-
ходом

Таблица 4.2 Формы команды арифметического сложения

Команда перехода (рисунок 4.9б) имеет только один операнд — точку перехода и задает безусловный переход. В MI нет отдельной команды условного перехода, а все условные ветвления выполняются в результате некой вычислительной команды. Так как переход является не вычисляемой командой, у нее нет разных форм, как у ADDN.

Третья команда (рисунок 4.9) имеет чудесное, хоть и немного длинное, имя «CPYBLAP» («Copy Bytes Left-Adjusted with Pad»). Она позволяет скопировать строку байтов из одного поля в другое. Байты выравниваются по левому краю принимающего поля, и если исходное поле короче принимающего, то оставшиеся байты будут заполнены заданным значением. Понятно, что это лишь одна из многих команд копирования в MI. В большинстве коммерческих приложений копирование используется очень интенсивно. Возможно, читатель узнал в «CPYBLAP» аналог оператору «Move» в языке Cobol или «MOVEL» с P в колонке полувыравнивания из RPG.

Мы рассмотрели лишь три команды MI (а есть еще сотни и сотни других) и только команды: MI (вычислительные и перехода) модели OPM. Как уже упоминалось, существуют также вычислительные команды и команды перехода для поддержки ILE. В следующих главах мы поговорим о командах для работы с объектами.

Выводы

Независимость от технологии, обеспечиваемая MI, чрезвычайно важна, так как позволяет избегать изменений в пользовательских приложениях и в OS/400. Все возможности нового оборудования могут быть задействованы сразу же после его установки.

Но это не единственное преимущество MI! Вычислительная среда со временем меняется: наглядные примеры — приложения клиент/сервер и концепция сетевых вычислений. Если бы AS/400, первоначально предназначенная для интерактивной работы, не смогла приспособиться к роли сервера, она бы уже давно устарела.

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

Глава 5

Объекты

Сетевые вычисления и Интернет сделали тему объектных технологий бестселлером компьютерных новостей. Распространение таких языков программирования, как Java и С++, заставляет разработчиков приложений изменить свое отношение к традициям и признать преимущества новых объектно-ориентированных языков.

Подобно другим технологиям, которые мы считаем новыми, объекты используются в программировании уже более 30 лет. Впервые они появились в конце 60-х годов в языках типа Simula 67, применявшихся для программ моделирования. Современные языки программирования, такие как Java, C+ + и Smalltalk — прямые потомки Simula 67. Программы моделирования имитируют поведение объектов реального мира. Аналогично, прикладные программы для бизнеса, содержащие объекты и операции над ними, моделируют реальные деловые отношения.

ОС работают с аппаратными и программными объектами, такими как устройства ввода-вывода и программы. Использование объектов в ОС выглядит совершенно естественным. О создании объектно-ориентированной ОС говорят многие фирмы, такие как Microsoft, Apple, Novell/USL (UNIX Systems Laboratory) и Sun Microsystems, однако, лишь немногие из них смогли реализовать свои планы. Одна из таких фирм — Next, уже поставляющая на рынок объектно-ориентированную ОС под названием NextStep.

Есть, конечно, и другая объектно-ориентированная ОС. С момента появления System/38 мы строим ОС (CPF и OS/400) по объектно-ориентированной модели[ 40 ]. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в главе 4, MI состоит из двух частей: команд и объектов. В этой главе мы рассмотрим использование объектов в AS/400.

Иногда говорят, что AS/400 это не объектно-ориентированная система, а система на основе объектов (object-based). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектно-ориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследование[ 41 ]. Как уже вкратце упоминалось в главе 3, наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/ 400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/

400 не просто использует или включает объекты, — они являются фундаментальной частью ее архитектуры.

В упрощенном виде объект — это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.

Еще одно достоинство объектов — целостность. Оригинальная System/3 была байтовой машиной (то есть все в ней располагалось на границе байта), а ее команды содержали однобайтовый код операции. Они занимали несколько последовательных байтов памяти, но никакого обязательного выравнивания команд не было. Более того, все разряды кода были задействованы для задания типа операции и местоположения операндов. Практически любая комбинация разрядов в байте могла быть интерпретирована как допустимый код операции System/3.

Это вызывало проблему, если в программе непреднамеренно происходил переход в область данных: процессор мог продолжать выбирать байты данных и интерпретировать их как команды. Такая программа могла исполняться долгое время, сея хаос внутри системы. Ликвидировать последствия таких ошибок было весьма сложно.

В этом плане System/3, ничем не отличалась от большинства других вычислительных систем того времени. Например, в обычной системе цепочка байтов может быть интерпретирована, практически, как угодно. Можно взять байты из одной части программы и перемножить их с байтами из другой ее части. Процессор «не волнует», имеет ли смысл такая операция. Он работает с байтами, а не с тем, что они представляют.

Итак, мы были очень обеспокоены проблемами целостности, и сделали все, чтобы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как «Создать объект», применимы ко всем объектам, другие — работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.

вернуться

40

Некоторые из нас, создателей System/38, были очень хорошо знакомы с языками компьютерного моделирования уже в конце 60-х. Я сам использовал объектные модели в своей докторской диссертации для компьютерного моделирования различных архитектур виртуальной памяти. Решение использовать объекты в System/38 пришло после нашего участия в проекте Future Systems (подробнее об этом см. в Приложении).

вернуться

41

Grady Booch. Object Oriented Design with Appliations. The Benjamin/Cummings Publishing Company, Inc. 1991.

35
{"b":"137615","o":1}