Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 10 (всего у книги 41 страниц)

Затраты на разработку SLIC

Создание вычислительной системы с высокоуровневым машинным интерфейсом и значительной частью ОС, расположенной под этим интерфейсом, было связано с определенными затратами. На разработку ПО пришлись основные расходы, связанные с AS/400. Давайте ненадолго остановимся и рассмотрим, почему так получилось.

SLIC содержит 3 миллиона строк надежного кода. (Под надежным имеется в виду код, который всегда должен работать правильно, чтобы обеспечить целостность и защищенность системы.) Так как SLIC – ядро ОС, мы не защищаем один его компонент от другого. Это совершенно обычный подход: ядра большинства ОС защищены от кода, расположенного вне его, но весь код внутри ядра считается надежным.

Если ядро невелико, скажем, состоит из 100 тысяч строк кода, то его целостность очень легко протестировать при каждом изменении. Если же строк 3 миллиона, то такое тестирование становится и сложнее, и дороже. Много лет мы в Рочестере использовали следующий подход: строго ограничивали круг тех, кому позволено работать с ядром, группой разработки и тестирования. Таким образом, код для SLIC могут написать заново только разработчики из Рочестера (впрочем, это достаточно большое число людей). Дополнительно надежность гарантируется тем, что разработчики действуют в условиях жесткой организационной структуры.

У подобного подхода есть и свои недостатки. Неоднократно сторонние организации, включая другие подразделения IBM, запрашивали у нас разрешение написать функции для SLIC. Во всех случаях мы отвечали твердым отказом: если позволить кому-либо написать хотя бы малую часть SLIC, то это может нарушить целостность всей системы, чего мы не допустим. Но следствие такого подхода – то, что создание новых функций SLIC жестко зависит от возможностей наших программистов. Мы практически никогда не можем позаимствовать код у кого-либо еще в IBM, по крайней мере, не на уровне SLIC.

В главе 4 мы рассмотрим, как компиляторы ЯВУ генерируют код PowerPC, исполняемый ниже MI. Мы увидим, что это требует использования компонента SLIC, известного как транслятор. Как и все компоненты SLIC, транслятор надежен, то есть должен всегда генерировать код, чтобы не нарушить целостность или защиту других компонентов системы. Трансляторы также разрабатываются только в подразделении SLIC в Рочестере.

Хорошо, что все функции SLIC работают как единое целое. Так как весь SLIC разрабатывался под одной крышей, мы достигли уровня целостности, о котором можно только мечтать в системах, разработка которых ведется «кусками». Использование общих программных компонентов в разных ОС может значительно сократить затраты, но не даст той интеграции функций, которой обладает AS/400. Что касается общих компонентов, то как мы увидим в следующем разделе, и здесь существует возможность подключения без нарушения целостности.

Технологии ядра в SLIC

В прошлом ядро каждой ОС было уникальным, мало кто брался разрабатывать ядро отдельно от ОС. Однако в середине 80-х годов положение стало меняться. В некоторых университетах, например, в Карнеги-Меллон (Carnegie-Mellon), начали изучение возможности использовать ядро с несколькими ОС. Именно там было спроектировано микроядро Mach, представляющее собой подмножество ядра, и выполняющее функции, необходимые большинству ОС.

Если одно и то же микроядро лежит в основе двух или нескольких ОС, то возможно исполнять эти ОС параллельно на одном и том же процессоре. Более того, такие ОС могут очень эффективно разделять ресурсы и взаимодействовать друг с другом. В последние годы операционные системы, выполняющиеся поверх одного микроядра, стали называть индивидуальностями (personality).

Так как SLIC разрабатывался в качестве нового ядра ОС, имело смысл включить в него технологии для поддержки множественных индивидуальностей. Фактически, большая часть такой поддержки уже имелась в оригинальном LIC. Например, для распределения процессора между ОС микроядро использует механизм передачи сообщений. Аналогичный подход использовался в оригинальной System/38 и был перенесен оттуда на AS/400. Подробно мы рассмотрим этот механизм в главе 9.

В то время, когда мы разрабатывали SLIC, в IBM были проведены исследования в области применения общих компонентов ОС на всех системах IBM, включая использующие процессор PowerPC. Одним из основных предложений было – принять в качестве базовой модели микроядро IBM, сконструированное по принципам микроядра Mach. В SLIC уже имелось большинство технологий микроядра, но возникали сомнения: следует ли нам в качестве всеобщей основы использовать микроядро IBM?. Ответ был совершенно очевиден. Единственно существовавшим в то время было 32-разрядное микроядро. Чтобы использовать это микроядро для AS/400, нужно было бы создать 64-разрядную версию. Перспективы возможности разделения ПО были также довольно туманны, кроме того, оставались вопросы по поводу масштабируемости этого микроядра (сколько пользователей сможет оно поддерживать?). Поэтому мы отвергли мысль использовать его в качестве основы для SLIC. Однако в Рочес-тере была создана группа для разработки 64-разрядных модификаций микроядра IBM с прицелом на будущее. Было также решено включить в SLIC возможности по поддержке множественных индивидуальностей ОС.

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

Индивидуальность System/36

В Рочестере была и группа разработчиков, продолжавших оставаться приверженцами System/36. В 1993 году в разгар работ над SLIC у двоих руководителей группы System/36, Дика Мастейна и Стива Дала (Steve Dahl), возникла идея. Почему бы не создать новую System/36? Такая возможность появлялась с переходом AS/400 на RISC и наличием в SLIC поддержки для других ОС. Упомянутые разработчики быстро подготовили предложения по переносу ОС System/36 на RISC-аппаратуру.

В предыдущие несколько лет различные производители по всему миру начали поставлять на рынок программные пакеты, позволявшие клиентам System/36 перейти на RISC-компьютеры: либо на RS/6000 IBM, либо на продукты конкурентов. Беда этих пакетов-«имитаторов» заключалась в том, что они предоставляли только часть возможностей System/36. Пользователям System/36 по-прежнему было необходимо вносить изменения в свои приложения и методы работы, а некоторые из программ для System/36 и вовсе не работали на новом компьютере.

В IBM был принят официальный план перевода пользователей System/36 на AS/ 400. Но лишь немногие заказчики воспользовались этой возможностью, а большинство отвергло ее. Согласно оценкам, более 200 000 System/36 по-прежнему работают в во всем мире. И все же многие в IBM полагали, что переход приверженцев System/ 36 на какую-либо новую платформу IBM – лишь вопрос времени. Не стоит и говорить, что в таких условиях предложение разработчиков о создании новой System/36 не было встречено с особым энтузиазмом.

По счастью, некоторые из рочестерских руководителей всегда хотели проверить новые возможности, и вскоре для разработки новой System/36 была создана «подпольная» группа («skunkwork»), что, впрочем, практиковалось в Рочестере и раньше[ 33 ]33
  Обычно такая «подпольная» группа представляет собой небольшое подразделение с нечеткой структурой, формируемое для продвижения инноваций, или иногда для сокрытия таковых. Названием «skunkwork» она обязана фабрике «Skonk Works» Бига Барнсмелла (Big Barnsmell), где подпольно производился напиток Kickapoo Joy, из комикса «Li'l Abner» в Al Capp.


[Закрыть]. Мы использовали такой трюк для разработки систем, которые не считались стратегическими и, таким образом, не финансировались централизованно. Вспомните, что и сама AS/400 появилась в результате подобной «подпольной» деятельности.

Итак, небольшая группа экспертов по System/36 под руководством Боба Шмидта (Bob Schmidt) вынуждена была скрываться от зорких глаз финансистов. Тем не менее, у Боба не было недостатка в добровольцах. Всего через несколько месяцев работы этой небольшой команды энтузиастов System/36 работала на новом RISC-процессоре. Серия продуктов System/36 получила новое дыхание.

Что-то старое, что-то новое

Процессор оригинальной System/3, появившейся на свет в 1969 году, был полностью реализован аппаратно. Он был очень прост и поддерживал всего 28 команд. Поверх аппаратуры System/3 функционировала ОС вместе со всеми приложениями. С появлением в 1975 году System/32 эта структура претерпела существенные изменения.

Уже в начале 70-х годов в процессе работ над System/38 перевод некоторых функций ОС в микрокод для достижения независимости от технологии был в Рочестере хорошо отлажен. Для поддержки набора команд System/3 в System/32 использовался микропрограммный эмулятор. По соображениям производительности некоторые функции были вынесены из ОС System/3 в микрокод System/32. Таким образом, System/32 и System/38 имели общие черты: некоторые части их ОС были реализованы в микрокоде, хотя и по разным причинам.

System/32 была разработана как система начального уровня и полностью соответствовала этому предназначению. Эмуляция набора команд System/3 выполнялась медленно, производительности процессора не хватало. Однако, процессор System/ 32 отлично выполнял эти функции. Примечательно, что сам он был 16-разрядным, использовал регистры и очень напоминал некоторые ранние RISC-процессоры.

Для повышения производительности System/32 требовались некоторые изменения. Ее процессор хорошо справлялся с выполнением ОС, так что было принято решение оставить его. Но поскольку он слишком медленно выполнял эмуляцию команд System/3, то был добавлен второй процессор, сходный с оригинальным процессором System/3, для исполнения команд последнего непосредственно аппаратурой. Значительная часть ОС была написана с помощью команд System/3 и должна была исполняться на втором процессоре. Так как он выбирал команды из основной памяти, второй процессор был назван MSP (Main Store Processor). Процессор же System/32 выбирал команды из отдельной области памяти, и был переименован в CSP (Control Store Processor). В 1977 была выпущена первая система на двух процессорах, названная System/34.

В 1983 году вслед за System/34 появилась модель System/36. Она по-прежнему использовала двухпроцессорную структуру. Подобно AS/400, чья ОС разбита на две части – OS/400 и SLIC – ОС System/36 также состояла из двух частей. Первая часть под названием SSP (System Support Program) исполнялась на MSP, а другая – на CSP. Старшие модели System/36 имели дополнительные процессоры для выполнения функций ввода-вывода. Они также представляли собой CSP, на которых исполнялись части ОС, управлявшие вводом-выводом. За следующие несколько лет были выпущены новые модели System/36, и все они также использовали два процессора.

В 1993 году разработчики System/36 пришли к выводу, что RISC-процессор, который предназначался для AS/400, достаточно быстр, чтобы эмулировать набор команд MSP без дополнительного процессора. Если соответствующий эмулятор встроить в SLIC вместе со всем кодом CSP, то ОС SSP могла бы выполняться новым RISC-процессором непосредственно. Для этого необходимо было создать эмулятор и переписать код CSP на С++ как часть SLIC.

Интерфейс между оригинальными MSP и CSP был интерфейсом SVC (Supervisor Call). Команда вызова супервизора (SVC) исполняется MSP и представляет собой запрос на выполнение CSP некоторых действий. Концептуально это то же самое, что и исполнение команды на уровне MI для запроса на выполнение некоторых действий SLIC. Разработчики рассудили, что если расширить MI включением интерфейса SVC, то SPP можно будет исполнять поверх MI, что позволит сделать SSP так же независящим от технологии. Соответствующее расширение MI было названо Technology Independent Emulation Interface (интерфейс эмуляции независящий от технологии)[ 34 ]34
  Этот интерфейс эмуляции также составил основу интерпретации Java на AS/400, что более подробно будет рассмотрено в главе 11. В отсутствие интерфейса эмуляции весь код MI перед исполнением надо было транслировать на аппаратный уровень. Теперь есть возможность выполнять часть кода MI путем интерпретации.


[Закрыть]

Приняв решение использовать для выполнения набора команд MSP не отдельный аппаратный процессор, а эмулятор, разработчики получили конструкцию, которая внутренне более походит на System/32, нежели на System/34 или System/36. Как часто происходит, история повторяется. В новом черном корпусе снова живет «bionic desk» (прозвище System/32)!

Advanced 36

Вот так внезапно мы получили совершенно новую System/36, работавшую на 64-разрядной RISC-аппаратуре с использованием ядра SLIC. Более того, это была System/ 36 в чистом виде. В SSP не было никаких изменений, затронувших интерфейсы приложений. Новая система была полностью двоично совместимой с System/36. Для переноса приложения на новую систему не требовалась даже перекомпиляции.

Очевидно, что эта новая индивидуальность System/36 могла бы выполняться на AS/ 400 с переходом на новые RISC-процессоры. Однако была и другая возможность – воссоздать раннюю версию процессора Cobra полностью (процессор, кэш и интерфейс ввода-вывода) на одном кристалле. В Рочестере была организована небольшая группа, которая вскоре получила однокристальный процессор, основывавшийся на дизайне ендикоттовской лаборатории. Этот процессор работал на частоте 50 МГц, что было достаточно быстро для любого приложения System/36. Процессор получил название Cobra-Lite, так как в нем не было реализовано примерно 17 команд из обязательного набора 64-разрядного PowerPC. Данные команды, по большей части для работы с плавающей точкой, были реализованы программно, но это не имело значения. Отсутствовавшие команды, включая комбинированную команду умножения и сложения с плавающей точкой, применяющуюся для матричных вычислений, не использовались в SLIC и не влияли на новую System/36.

IBM подтвердила, что ее завод в Барлингтоне может производить специальные микросхемы в количестве, достаточном для выпуска новых System/36 на RISC-процессорах в конце 1994 года. Мы знали, что можем включить в этот продукт раннюю версию SLIC с новой версией SSP.

Перед нами была непростая дилемма. Можно начать выпуск первого 64-разрядного RISC-компьютера IBM – но это System/36! Мы много лет призывали своих заказчиков отказаться от System/36, а теперь были готовы выпустить ее новую версию на основе самой современной технологии. Принять такое было нелегко. Подразделения IBM по всему миру отвергли новую System/36. Наконец, мы убедили руководство позволить нам самим поговорить с заказчиками и бизнес-партнерами и предоставить рынку решать, следует ли нам объявлять в 1994 году о новой системе. Я делал доклад о новой System/36 на самой большой конференции наших бизнес-партнеров в начале 1994 года. Подавляющее большинство аудитории проголосовало за объявление новой системы. Многие были готовы прямо на месте купить у нас демонстрационную машину. Руководство и службы маркетинга IBM быстро оценили потенциал новой системы. В октябре 1994 года Advanced 36 появилась на рынке, где сразу же стала пользоваться спросом.

Первая модель 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 старое изречение: «Целое больше, чем простая сумма частей».

Глава 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.