Текст книги "Основы AS/400"
Автор книги: Фрэнк Солтис
Жанр:
ОС и Сети
сообщить о нарушении
Текущая страница: 12 (всего у книги 41 страниц)
Внутри шаблона программы
Чтобы выяснить, что там происходит, возьмем в качестве примера шаблон программы ОРМ, хотя он и не поддерживается на RISC-системах. Я выбрал ОРМ по двум причинам. Во-первых, это дает возможность рассмотреть еще несколько интересных концепций, лежащих в основе оригинального набора команд MI. Во-вторых, некоторые детали шаблона программы ILE не опубликованы. И поэтому прежде чем заняться шаблоном программы ОРМ, рассмотрим те изменения, которые были внесены в программную модель ILE.
При создании компиляторов для программной модели ILE, в MI были добавлены новые команды. Некоторые из них имеют структуру близкую к W-коду, используемому компиляторами ILE, однако не совпадают с его командами в точности. Права на W-код принадлежат лаборатории IBM в Торонто (Toronto), Канада, которая пока не желает лицензировать интерфейс W-кода кому-либо за пределами IBM, опасаясь, что другие смогут разрабатывать и продавать компиляторы для AS/400. Мы решили определить команды! MI, которые похожи, но не в точности совпадают с W-кодом, чтобы не связываться с Торонто, если там когда-либо будет принято решение открыть этот интерфейс другим фирмам.
Наилучший целевой компьютер для компиляторов ILE – стековая машина, поэтому MI был расширен для поддержки стеков. Стек – набор данных, хранящихся последовательно. Первый помещенный в стек элемент называется его дном, последний – вершиной. Для работы со стеком используются команды без явного указания операндов, которые определяются путем извлечения из стека двух верхних элементов. В противоположность этому, команды ОРМ имеют два операнда, заданных непосредственно в команде. Для стековой машины операция задается после операндов. Такая форма записи называется постфиксной или обратной польской в честь математика Лукашевича (J. Lukasiewicz), исследовавшего ее свойства[ 37 ]37
Правильней было бы назвать эту запись «записью Лукашевича». К сожалению, немногие американцы могут правильно произнести или написать эту фамилию, так что прижилось название «польская».
[Закрыть].
Интересно, что архитектура, разработанная в 1972 году, имела аналогичную поддержку стека. В то время многие полагали, что блочно-структурированные языки, такие как PL/1, станут очень популярными. Но они так и не вытеснили RPG и Cobol, так что стек был временно отвергнут. Теперь, с появлением таких языков как С, мы снова вернулись к нему.
Рисунок 4.7 Команды и ODT
Шаблон программы состоит из нескольких частей. Шаблон программы ОРМ содержит заголовок, последовательность команд MI, пользовательские данные и структуру под названием таблица определения объектов ODT (object definition table). Команды и ODT представлены на рисунке 4.7. Последовательность команд на рисунке содержит пример команды MI. Использована классическая команда OPM с тремя операндами —арифметическое сложение. Она состоит из кода операции, за которым следуют три значения, используемые для поиска трех операндов. Каждое из них является индексом в ODT. Показанная на рисунке команда запрашивает сложение операнда 6 с операндом 2 и помещение суммы в операнд 3.
ODT состоит из двух компонентов. Первая – ODV (ODT Direction Vector) – содержит по одному элементу для каждого операнда программы. Все элементы имеют одинаковую длину, так что значение из последовательности команд может использоваться как индекс в ODV. Элементы ODV описывают операнды. В нашем примере, операнды 6 и 3 – это двоичные числа длиной 2 байта, а операнд 2 – константа. Константы и другие типы операндов могут иметь переменную длину, что задает необходимость второго компонента ODT. OES (ODT Entry String) содержит операнды переменной длины, не умещающиеся в ODV. Содержимое поля ODV указывает на начало цепочки в OES. В нашем примере операнд 2 представляет собой константу 1253.
Пример иллюстрирует несколько характеристик команд MI модели ОРМ. Во-первых – это команда арифметического сложения. Это не команда двоичного или десятичного сложения, или сложения с плавающей запятой; она универсальна. Формат операндов команды определяется в ODT. В нашем примере используются двоичные целые операнды, но они могли бы иметь любой числовой формат. За генерацию необходимых преобразований отвечает транслятор.
Во-вторых, из примера видно, что ОРМ MI – неисполняемый интерфейс. Обратите внимание, что ни с операндом 3, ни с операндом 6 не связаны значения. Элемент ODV эквивалентен объявлению переменной. Память для переменной не выделена, так что транслятор обязан завершить компиляцию и назначить переменным регистры или области памяти.
И, наконец, в примере показана обычная вычислительная команда. Команда, работающая с объектом, имела бы аналогичный формат, но в ODT было бы указано, как найти объект (детали адресации объектов будут рассмотрены в главе 5).
Форматы команд MI
Рисунок 4.8 Формат команд MI
На рисунке 4.8 показан формат команд ОРМ MI в потоке команд. Команда состоит из кода операции, необязательного расширения кода операции, а также нуля или более операндов. MI проектировался в расчете на последующие расширения, так что формат команды допускает увеличение числа команд и операндов. Код операции и его расширение представляют собой 16-разрядные поля. Поле операнда, используемое как индекс в ODV, первоначально на System/38 имело длину 16 бит, но затем было расширено до 24 бит. Это означает, что в программе может быть до 16 миллионов (224) разных операндов, и эта цифра может быть увеличена.
Экономия памяти не была слишком важна для шаблона программы. Например, команда арифметического сложения заняла бы 2 байта для кода операции, 2 байта – для расширения кода операции и 9 байтов – для операндов. Получается 13 байтов, и мы еще не учли пространство для операндов в ODT. Не удивительно, что пользователи System/36 были недовольны объемом дискового пространства, занимаемого программами.
Код операции MI
В таблице 4.14 показано назначение битов кода операции MI. Бит 3 задает вычислительный или невычислительный формат команды. Во втором случае функция, которая должна быть выполнена, закодирована в битах 5-15 кода операции. Функция, выполняемая вычислительной командой, задается битами 8-15. В этом случае, как в примере с арифметическим сложением, биты 5-7 содержат дополнительную информацию о команде.
Бит 6 вычислительного формата указывает, должно ли производиться округление. Обычно, округление характерно для арифметики с плавающей запятой, однако, проектировщики MI имели в виду не это. AS/400 – это машина для коммерческих расчетов, и округление, используемое в MI – это десятичное округление. Десятичные данные рассматриваются как данные с плавающей десятичной запятой.
Бит 7 указывает на сокращенную форму команды, что также имеет смысл только для вычислительных команд. В нашем примере арифметического сложения участвуют три операнда. Два из них складываются, и результат помещается в третий, то есть два первых операнда не изменяются. Сокращенная команда также складывает первые два операнда, но результат помещается в первый операнд. Таким образом, сокращенная команда использует формат только с двумя операндами.
Таблица 4.1 Назначение битов кода операции
Наконец, в вычислительном формате имеются два бита, описывающих расширение кода операции. Биты 4 и 5 определяют наличие расширения и если таковое присутствует – способ его использования. Это требует более подробного объяснения.
Расширение кода операции
Расширение кода операции MI занимает следующие 16 бит команды и имеет две формы: опция перехода и опция индикации. Наличие расширения задается установкой бита 4, а в положительном случае разряд 5 выбирает опцию перехода или индикации.
В случае использования опции перехода расширение кода операции делится на четыре 4-разрядных поля. Каждое из них применяется для определения возможностей перехода для данной команды. В процессе исполнения любой вычислительной команды MI возможен условный переход. Другими словами, в зависимости от результатов вычисления следующая команда MI может быть выбрана из некоторого другого места последовательности команд.
Рассмотрим первое 4-разрядное поле расширения. Значение 1 (двоичное 0001) в этом поле означает переход в том случае, если в результате вычисления получено положительное число. Значение 2 (двоичное 0010) задает переход при отрицательном значении результата. Если же поле имеет значение 4 (двоичное 0100), то переход выполняется при результате равном 0. Имеются также значения для перехода при ненулевом, неположительном, неотрицательном и не ненулевом результате. Кроме того, та же самая комбинация битов может иметь разный смысл для разных типов команд. Например, команда сравнения интерпретирует биты иначе, чем команда сложения.
Если условие перехода, заданное первым 4-разрядным полем выполнено, то цель перехода может быть найдена за последним операндом команды. Если условие перехода не выполнено, то будет исполняться следующая команда по порядку. Такие возможности команд приводят к увеличению их длины.
Так как каждое из четырех 4-разрядных полей расширения используется для задания условия перехода, то каждая вычислительная команда может содержать до
четырех условий и до четырех целей перехода. Если нужно менее четырех условий, то значение 0 задает отсутствие перехода.
Возможность MI выполнять переход в четыре точки после каждой вычислительной команды обеспечивает набору команд большую мощность за счет их удлинения. В примере с арифметическим сложением – до четырех целей перехода, что увеличивает длину команды еще на 12 байтов. Команда может занимать в памяти до 25 байтов. Это не создает проблем во время выполнения, так как команды: MI не исполняются непосредственно. Однако размер программы увеличивается.
Опция индикатора работает аналогично опции перехода. Расширение содержит те же четыре 4-разрядных поля с теми же возможными значениями. Отличие в том, что вместо перехода при выполнении условия устанавливается индикатор. Индикатор представляет собой переменную в памяти, содержащую десятичные значения 1 или 0. Если в процессе выполнения вычислительной команды условие, заданное 4-разрядным полем, выполнено, то индикатор устанавливается в значение 1, в противном случае —в значение 0. Как и в случае перехода, в команде может быть задано до четырех индикаторов, которые указываются следом за операндами.
Многие читатели узнали в этом описании индикаторы RPG. Возможность установить индикатор и затем, в зависимости от его значения, выполнить некоторое действие восходит к оборудованию обработки единичных записей. Индикаторы RPG поддерживаются набором команд MI непосредственно[ 38 ]38
Многие годы ходила шутка, что безотказный прием для того, чтобы собрать большую аудиторию на конференции пользователей – включить слово «индикатор» в название презентации. По общему мнению, зал будет забит до отказа.
[Закрыть]. На первый взгляд, эта возможность кажется устаревшей. Однако многие самые современные RISC-процессоры используют прием записи в регистр значения 0 или 1 для индикации результата вычисления. То есть, индикаторы живы и в добром здравии.
Примеры команд MI
Рисунок 4.9а Команда арифметического сложения (ADDN)
На рисунках 4.9а, 4.9б и 4.9в показаны форматы трех команд ОРМ MI. Команда арифметического сложения ADDN имеет шестнадцатиричный[ 39 ]39
Шестнадцатиричные числа – элемент системы счисления с основанием 16. В этой системе используются 16 цифр 0-9 и А-F. Часто для краткости в шестнадцатиричном виде представляют наборы битов. Каждое 4-битное поле может быть представлено одной шестнадцатиричной цифрой. Так, двоичное 0001 в шестнадцатиричной системе будет 1, 0010 – 2... 1111 – F.
[Закрыть] код операции 1043, а также три операнда. Это вычислительная команда, и функция сложения в ней имеет код 43.
Рисунок 4.9b Команда перехода (B)
Рисунок 4.9c Копирование байтов с выравниванием влево и заполнителем (CPYBLAP)
В таблице 4.27 приведены 11 других форм ADDN. Различные варианты команды получаются путем комбинации опций сокращенной команды, округления, индикатора и перехода. Обратите внимание, что кодом функции по-прежнему остается 43.
| ADDNS | 1143 | Короткая |
| ADDNR | 1243 | С округлением |
| ADDNSR | 1243 | Короткая с округлением |
| ADDNI | 1843 | Индикаторная |
| ADDNIS | 1943 | Индикаторная короткая |
| ADDNIR | 1A43 | Индикаторная с округлением |
| ADDNISR | 1B43 | Идикаторная короткая с округлением |
| ADDNB | 1C43 | С переходом |
| ADDNBS | 1D43 | Короткая с переходом |
| ADDNBR | 1E43 | С оКороткая с округлением и с пере- |
| ходом |
Таблица 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 ]40
Некоторые из нас, создателей System/38, были очень хорошо знакомы с языками компьютерного моделирования уже в конце 60-х. Я сам использовал объектные модели в своей докторской диссертации для компьютерного моделирования различных архитектур виртуальной памяти. Решение использовать объекты в System/38 пришло после нашего участия в проекте Future Systems (подробнее об этом см. в Приложении).
[Закрыть]. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в главе 4, MI состоит из двух частей: команд и объектов. В этой главе мы рассмотрим использование объектов в AS/400.
Иногда говорят, что AS/400 это не объектно-ориентированная система, а система на основе объектов (object-based). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектно-ориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследование[ 41 ]41
Grady Booch. Object Oriented Design with Appliations. The Benjamin/Cummings Publishing Company, Inc. 1991.
[Закрыть]. Как уже вкратце упоминалось в главе 3, наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/ 400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/
400 не просто использует или включает объекты, – они являются фундаментальной частью ее архитектуры.
В упрощенном виде объект – это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.
Еще одно достоинство объектов – целостность. Оригинальная System/3 была байтовой машиной (то есть все в ней располагалось на границе байта), а ее команды содержали однобайтовый код операции. Они занимали несколько последовательных байтов памяти, но никакого обязательного выравнивания команд не было. Более того, все разряды кода были задействованы для задания типа операции и местоположения операндов. Практически любая комбинация разрядов в байте могла быть интерпретирована как допустимый код операции System/3.
Это вызывало проблему, если в программе непреднамеренно происходил переход в область данных: процессор мог продолжать выбирать байты данных и интерпретировать их как команды. Такая программа могла исполняться долгое время, сея хаос внутри системы. Ликвидировать последствия таких ошибок было весьма сложно.
В этом плане System/3, ничем не отличалась от большинства других вычислительных систем того времени. Например, в обычной системе цепочка байтов может быть интерпретирована, практически, как угодно. Можно взять байты из одной части программы и перемножить их с байтами из другой ее части. Процессор «не волнует», имеет ли смысл такая операция. Он работает с байтами, а не с тем, что они представляют.
Итак, мы были очень обеспокоены проблемами целостности, и сделали все, чтобы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как «Создать объект», применимы ко всем объектам, другие – работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.
На эту проблему можно взглянуть и с другой стороны. В большинстве ОС, все, что находится в постоянной памяти, считается файлом (в MS-DOS или MVS файлом называют набор данных). Файлы могут иметь различное назначение, но такая классификация определяется лишь по соглашению. Вы можете читать объект-программу так, как если бы это был файл. В OS/400 это невозможно (как и создать вирус, по крайней мере, в слое над MI), так как термин «файл» применим лишь к небольшому числу типов объектов, и программа определенно файлом не является. Кстати, с этим связаны некоторые неудобства, присутствовавшие в System/38, где значительная часть информации об объектах была недоступна программам. COMMON (группа пользователей AS/400) многократно просила включить во все команды отображения, такие как, например, «DSPOUTQ» («Display Output Queue»), «DSPJOBQ» («Display Job Queue»), опцию генерации выходного файла, чтобы информация, хранящаяся внутри объектов, могла быть считана программно. В конце концов, мы добавили такую возможность в некоторые команды:, которые первоначально ей не обладали (а в «DSPOUTQ» и «DSPJOBQ» ее нет и сейчас). Но исчерпывающим ответом на эти запросы было создание API, позволяющих поместить информацию об объектах и системе в объект, известный как пользовательское пространство. Этот объект программы могут читать быстрее, чем файлы базы данных.
