Фрэнк Солтис - Основы AS/400

Первая модель Advanced 36 исполняла только ОС SSP. Последующие модели могут исполнять OS/400 и SSP параллельно на одном и том же процессоре. Advanced 36 продемонстрировала всю мощь архитектуры AS/400 и ее способность прозрачно интегрировать новую функциональность и даже целую новую ОС. Теперь внутри SLIC каждой RISC-модели AS/400 «живет» System/36. Может, имеет смысл на каждую новую AS/400 приклеивать метку «System/36 Inside»?

Интеграция обеспечила уникальные возможности AS/400. Компоненты разработаны для взаимодополняющей совместной работы друг с другом. Интеграция также затрудняет изучение компонентов по отдельности, как в других системах. Например, ранее мы говорили, что защита реализована частично в OS/400 и частично — в SLIC. Изучение только защиты OS/400 не дает полной картины. Сравните это с другими системами, где компонент защиты представляет собой отдельный самодостаточный пакет, работающий поверх ОС.

Рассматривать AS/400 как набор горизонтальных слоев не результативно. Лучше понять систему можно, «делая» ее вертикальные срезы, — то есть изучая конкретную функцию, части которой реализованы в OS/400, в SLIC и в аппаратуре как единое целое.

В следующей главе мы рассмотрим слой MI. Это позволит лучше понять типы функций, реализованных в OS/400 и в SLIC. Мы также увидим, каким образом программа, прежде чем выполняться, компилируется до уровня аппаратуры.

Далее мы поговорим об основных компонентах AS/400 как о ряде вертикальных срезов. После этого Вы увидите, как справедливо в приложении к AS/400 старое изречение: «Целое больше, чем простая сумма частей».

Итак, после того, как к большинству компьютерных систем были добавлены уровни абстракции, их архитектура стала многоуровневой. Главные уровни 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 не привязано к аппаратуре. Это не физический, а логический интерфейс системы. Как уже говорилось в главе 1, архитектура MI предлагает полный набор API для OS/400 и всех приложений. Этот набор полон по определению; то есть ни система, ни приложения в принципе не могут выйти за пределы MI. Единственный способ связи с аппаратурой и некоторым системным ПО ниже MI — через сам MI. Это свойство отличает архитектуру MI от API-центрической архитектуры, где приложения могут обходить API и, следовательно, становиться зависимыми от нижележащих аппаратуры и ПО.

Когда создавалась архитектура MI, термин API еще не был четко определен, так что разработчики называли эти модификации просто командами. Чтобы показать, что интерфейс архитектуры поддерживает как прикладное, так и системное ПО, они выбрали название машинный интерфейс. Так что можно считать, что «I» в аббревиатуре «API» — то же, что и в «MI». API — не что иное, как команды MI.