Основы AS/400

 
Выводы
Интеграция обеспечила уникальные возможности AS/400. Компоненты разработаны для взаимодополняющей совместной работы друг с другом. Интеграция также затрудняет изучение компонентов по отдельности, как в других системах. Например, ранее мы говорили, что защита реализована частично в OS/400 и частично — в SLIC. Изучение только защиты OS/400 не дает полной картины. Сравните это с другими системами, где компонент защиты представляет собой отдельный самодостаточный пакет, работающий поверх ОС.
Рассматривать AS/400 как набор горизонтальных слоев не результативно. Лучше понять систему можно, «делая» ее вертикальные срезы, — то есть изучая конкретную функцию, части которой реализованы в OS/400, в SLIC и в аппаратуре как единое целое.
В следующей главе мы рассмотрим слой MI. Это позволит лучше понять типы функций, реализованных в OS/400 и в SLIC. Мы также увидим, каким образом программа, прежде чем выполняться, компилируется до уровня аппаратуры.
Далее мы поговорим об основных компонентах AS/400 как о ряде вертикальных срезов. После этого Вы увидите, как справедливо в приложении к AS/400 старое изречение: «Целое больше, чем простая сумма частей».
 
Глава 4
 
Машинный интерфейс, независимый от технологии
Итак, после того, как к большинству компьютерных систем были добавлены уровни абстракции, их архитектура стала многоуровневой. Главные уровни AS/400 — это архитектура независимого от технологии машинного интерфейса MI (Technology Independent Machine Interface) и архитектура RISC-процессора PowerPC.
Определение архитектуры PowerPC было дано с очевидным уклоном в сторону аппаратуры. Конструкторы микросхем играют важную роль в создании любой процессорной архитектуры — ведь именно они держат в голове массу вариантов ее реализации. Дабы не выйти за пределы возможностей конкретной аппаратуры конкретного кристалла, соблюсти время процессорного цикла, от одних функций им приходится отказываться, другие — определять заново. Это единственно верный подход — ведь в нереализуемой аппаратной архитектуре смысла мало. В то же время архитектура, учитывающая только требования аппаратуры, недолговечна.
Правда, есть и опирающиеся на аппаратуру архитектуры-долгожители. Например, Intel успешно довела свой процессор x86 с начала 80-х до сего дня. Начав с Intel 8086, эта компания продолжает наращивать его функциональные возможности, по мере того как технология позволяет упаковать все больше транзисторов в один кристалл. Семейство процессоров 186, 286, 386, 486, Pentium, Pentium II и Pentium Pro — грандиозный успех Intel.
Для поддержания программной совместимости к оригинальной 16-разрядной архитектуре были добавлены 32-разрядные расширения. С этой же целью новые (1997 год) команды расширений мультимедиа (MMX) используют существующие регистры с плавающей запятой, а не добавляют новые. С целью повысить конкурентоспособность и производительность Intel добавила в процессоры Pentium Pro и Pentium II набор микрокоманд RISC. Каждая CISC-команда x86 реализована в этих процессорах как последовательность RISC-команд. Благодаря использованию RISC-техноло-гии архитектура x86 продолжает жить.
 
Обзор архитектуры MI
Определение архитектуры MI не привязано к аппаратуре. Это не физический, а логический интерфейс системы. Как уже говорилось в главе 1, архитектура MI предлагает полный набор API для OS/400 и всех приложений. Этот набор полон по определению; то есть ни система, ни приложения в принципе не могут выйти за пределы MI. Единственный способ связи с аппаратурой и некоторым системным ПО ниже MI — через сам MI. Это свойство отличает архитектуру MI от API-центрической архитектуры, где приложения могут обходить API и, следовательно, становиться зависимыми от нижележащих аппаратуры и ПО.
  
Когда создавалась архитектура MI, термин API еще не был четко определен, так что разработчики называли эти модификации просто командами. Чтобы показать, что интерфейс архитектуры поддерживает как прикладное, так и системное ПО, они выбрали название машинный интерфейс. Так что можно считать, что «I» в аббревиатуре «API» — то же, что и в «MI». API — не что иное, как команды MI.
Вы поражены прозорливостью разработчиков первоначальной архитектуры MI, раз и навсегда определивших набор API, используемый OS/400 и всеми приложениями? Не стоит: они не сделали этого, да и не могли сделать. По мере появления новых приложений в архитектуру MI добавлялись поддерживающие их новые API. Дело в том, что архитектура MI безразмерна, и новые API для поддержки новых приложений или функций операционной системы к ней можно добавлять в любое время. А раз эта архитектура постоянно изменяется, приобретая новые функции, то значит, она никогда не устареет. Так как все предыдущие API остаются при этом нетронутыми, для всех ранее написанных приложений сохраняется защита в границах MI.
Архитектура MI состоит из двух компонентов: набора команд и операндов, над которыми эти команды выполняются. Часть операндов — из битов и байтов — не отличается от тех, что используются в обычных компьютерных архитектурах. Другие представляют собой объекты. Объект — это сложная структура данных, единственная, поддерживаемая в рамках MI.
Компьютер обычно представляет свои информационные ресурсы — каталоги, файлы баз данных и описания физических устройств — в виде структур данных или хранящихся в памяти блоков с заранее определенными полями. Приложения и системное ПО, обладая непосредственным доступом к этим структурам данных, манипулируют их полями. А следовательно, они должны «знать», как это делать.
Объект в границах MI — это контейнер, содержащий структуру данных, соответствующую информационному ресурсу. Определенный уровень независимости достигается следующим образом: прикладные и системные программы вместо того, чтобы работать непосредственно со структурой данных через инструкции на уровне битов и байтов, имеют дело лишь с инструкциями, рассматривающими объекты в целом.
Благодаря использованию объектов, прикладному и системному ПО больше не требуется информация о структуре или формате данных. Эта информация хранится в контейнере и невидима за пределами объекта. Поэтому любые изменения в структуре данных не влияют на прикладные или системные программы, и они остаются независимыми от структур нижнего уровня. Такое свойство сокрытия внутренних деталей называется инкапсуляцией. Мы обсудим инкапсуляцию, а также внутреннюю структуру объекта и команды для работы с ними в главе 5, а теперь сосредоточимся на наборе команд архитектуры MI.
Давайте обсудим несколько примеров команд, выполняемых над обычными данными и команд, оперирующих объектами. Поговорим и о том, как компиляторы используют MI для генерации кода, выполняемого аппаратурой, познакомимся с характеристиками MI и программами MI. И наконец, рассмотрим структуру команд MI.