System Licensed Internal Code (SLIC) —сердце AS/400
Часто возникает некая терминологическая путаница: что, собственно, является операционной системой AS/400? Первое, что приходит в голову — ну, конечно, это Operating System/400 (OS/400); в конце концов, иначе ее не называли бы так. И все же такой ответ неверен. OS/400 нельзя признать операционной системой AS/400, так как в ней не предусмотрены большинство функций, присущих другим ОС.
В главе 1 мы определили ОС как набор программ, управляющих системными ресурсами и предоставляющих базу для написания прикладных программ. Мы также оговорили, что законченный набор API для написания приложений для AS/400 — это MI, высокоуровневый машинный интерфейс. Таким образом, на вторую часть вопроса мы ответили. Осталось решить, где же находятся программы, управляющие системными ресурсами.
И снова ответ «OS/400» будет неверен. Компоненты традиционной ОС выполняют такие функции как управление памятью, процессами, программами и вводом-выводом. Но, обычно, эти низкоуровневые функции сильно зависят от аппаратуры и тесно связаны с нижележащими физическими структурами. Например, компонент управления памятью должен «знать» точную конфигурацию и характеристики иерархии памяти. Независящий от технологии интерфейс MI не обладает этими качествами. Следовательно, управление памятью должно осуществляться ниже MI, OS/400 же, наоборот, расположена выше. Следовательно, ни одна из таких аппаратно-зависимых компонент не может быть в ее составе, этого не допускает основное условие задачи — независимость от технологии.
Итак, благодаря расположению аппаратно-зависимых компонентов ниже MI, последний защищает прикладные программы и OS/400 от аппаратных изменений. ПО операционной системы, расположенное ниже MI, называется LIC (licensed internal code).
Давайте еще раз взглянем на структуру AS/400. Теперь очевидно: OS/400 состоит из объектов и программ поверх MI, а LIC составляют структуры данных и программы ниже MI. Таким образом, LIC связывает MI и аппаратуру. Фактически, ОС AS/ 400 — сочетание OS/400 и LIC. Получается, что AS/400 представляет собой пирог, в котором OS/400 играет роль глазури, а LIC — начинки между слоями.
В последние годы такую нижнюю часть ОС в других системах стали называть ядром. Есть много определений того, что именно относится к ядру операционной системы. Некоторые педанты могли бы сказать, что LIC содержит гораздо больше функций операционной системы, чем, обычное ядро. И все же термин ядро наиболее удобнен для описания функций ОС, реализованных ниже MI.
Разделяй и властвуй
Очевидно, что некоторые компоненты ОС, такие как управление памятью, реализованы в LIC. Для других компонентов это не столь очевидно. Возьмем, например, базу данных. Некоторым ее частям необходима информация о физических дисковых устройствах и о пересылке данных в системе, другие же — могут быть написаны аппа-ратно независимо. Проектировщики обязаны решить, где разместить ПО базы данных — целиком в OS/400, целиком в LIC или и там, и там.
Рискуя забежать вперед (подробно мы рассмотрим MI в главе 4) должен отметить, что, говоря о разделении на OS/400 и LIC, я имею в виду объекты MI, реализованные в LIC. Позже мы подробней остановимся на системных объектах MI, реализованных в LIC, и на объектах OS/400, реализованных только MI.
Конечно, все функции OS/400 присутствуют в LIC в том смысле, что они должны использовать MI для обращения к аппаратуре. Но часто инструкция на ЯВУ после преобразования в соответствующую форму MI транслируется в команды PowerPC (или старого IMPI) напрямую, без каких-то особых структур данных или вызовов процедур LIC. Считать, что некоторая системная функция реализована OS/400, а не LIC, можно в тех случаях, если реализующий ее код видим OS/400 и необходимые структуры данных находятся в объектах OS/400 или в их видимых частях.
На рисунке 3.1 показано распределение функций ОС между OS/400 и LIC. Некоторые функции, такие как управление планированием заданий, могут быть реализованы в основном в OS/400, так как мало зависят от аппаратуры. Другие, такие как поддержка устройств — частично в OS/400, а частично в LIC. Общие характеристики устройств могут поддерживаться OS/400. Например, информация о том, что устройство является принтером, не привязывает прикладную программу к конкретному принтеру. А вот информация о деталях потока данных принтера вызывает подобную привязку и должна использоваться в LIC, ниже MI.
Рисунок 3.1 Распределение функций AS/400
Некоторые аппаратно-независимые функции ОС также реализованы ниже MI, например, защита. Эта функция не зависит от аппаратуры, и таким образом может быть осуществлена целиком в OS/400 поверх MI. Однако реализация части защиты ниже MI обусловлена требованиями безопасности. Подробнее о том, как осуществляется общесистемная защита в OS/400, а контроль доступа к системным ресурсам — в LIC, мы поговорим в главе 7.
Подобно защите, большинство функций ОС реализованы частично над, а частично — под MI. Даже отдельный компонент некоторой функции ОС может быть реализован по обе стороны этой границы. На рисунке 3.1 показаны некоторые компоненты базы данных и их распределение относительно MI.
Другая причина расположения некоторой функции или части ее ниже MI — производительность. Общий принцип таков: чем более функция аппаратно-зависима, тем лучше ее можно настроить для максимальной производительности. Реализация ниже MI не гарантирует повышение производительности для всех функций, но в некоторых случаях может помочь. Недостаток такого подхода — увеличение объема кода ОС, зависящего от аппаратуры.
Микрокод
Ранее микропрограммирование было определено как технический прием, при котором программирование внутреннего компьютера служит цели эмуляции операций внешней вычислительной архитектуры. Соответствующее ПО часто называют микрокодом.
В System/38 было два разделенных IMPI слоя микрокода ниже MI: горизонтальный микрокод HMC (Horizontal Microcode) и вертикальный микрокод VMC (Vertical Microcode). Самым низким уровнем был HMC, использовавший специализированный набор микрокоманд, исполняемый аппаратурой процессора непосредственно. Он содержал микропрограммируемый эмулятор, выполнявший команды IMPI. В состав HMC были также включены некоторые функции ОС самого низкого уровня. HMC был спроектирован так, чтобы обеспечить высокопроизводительный параллелизм работы процессора. Из-за этого ЯВУ для написания такого кода не существовало, а программирование было очень сложным и требовало много времени.
Вторым слоем, расположенным под MI, но над IMPI, был VMC. В этом слое содержались те аппаратно-зависимые функции ОС, которые не были реализованы в HMC. VMC был написан частично на специализированном ЯВУ, разработанным внутри IBM для системного программирования, и частично на ассемблере IMPI. Он не был микрокодом в традиционном смысле; а представлял собой самый нижний уровень ПО ОС.
Ядро операционной системы System/38 было названо микрокодом во избежание коммерческих проблем, типичных для 60-х годов. Тогда среди компьютерных гигантов, включая IBM, была распространена следующая практика: связывать получение системного ПО с требованием покупать фирменную аппаратуру. Так продолжалось до тех пор, пока различные фирмы ни создали множество компьютеров, совместимых с мэйнфреймами IBM (сегодня, мы назвали бы их клонами), для продажи по более низкой цене. Производители совместимой аппаратуры получали прибыль только в том случае, если бы покупатели могли приобретать ОС IBM без аппаратных средств. Под угрозами судебных преследований IBM согласилась в будущем не привязывать ПО к своим компьютерам.
С System/38 проблема связанных продаж ПО и аппаратуры возникла вновь. Мы хотели получить систему, единственным внешним интерфейсом которой был бы MI. Если бы мы продавали только аппаратные средства, то потеряли бы обеспеченную
MI независимость от технологии. Для выхода на рынок годился только законченный машинный продукт MP (Machine Product), который бы содержал аппаратные средства плюс ядро ОС.
Чтобы выйти из положения, ядро назвали микрокодом, позаимствовав этот термин у разработчиков проекта IBM Future Systems, которые еще в начале 70-х также пытались объединить некоторые функции ПО с аппаратурой. Так как микрокод рассматривался как часть аппаратуры, то тем самым мы не нарушали соглашения и были чисты перед законом. Все затраты по разработке VMC должны были быть отнесены на аппаратные средства. По тем же соображениям для написания VMC необходимо было создать проектную организацию, отдельную от группы программирования. Именно этим и объясняются разные названия сходных функций и структур в OS/400 и VMC (см. последующие главы).
С появлением AS/400 названия двух слоев микрокода были изменены. Сегодня наши заказчики могут покупать аппаратное, но не программное обеспечение. Вместо этого они приобретают лицензию на использование ПО (иногда — только для определенной системы) и не могут изменять, копировать или перепродавать его, если это не разрешено лицензией. Микрокод же — часть аппаратуры, а следовательно, покупатель может владеть им. Так как при объявлении AS/400 вопрос о связывании более не стоял (сегодня мы продаем даже OS/400 в едином комплекте с аппаратурой), то IBM решила переименовать микрокод System/38. Таким образом, у AS/400 имеется вертикальный LIC VLIC (Vertical Licensed Internal Code) и горизонтальный LICHLIC (Horizontal Licensed Internal Code).
С появлением новых RISC-процессоров потребовалось еще одно изменение названия. HLIC содержал микропрограммируемый эмулятор, необходимый для реализации IMPI. Так как у RISC-процессора микропрограммируемого эмулятора нет, то нет и HLIC, остается только VLIC. В связи с этим при переходе на RISC-процессоры, функции ОС, ранее выполняемые в HLIC, были переписаны для VLIC. И когда остался единственный слой внутреннего кода, мы с радостью отбросили, наконец, бессмысленные названия «вертикальный» и «горизонтальный».
Впереди скользкая дорога
Вопрос: Что содержит более трех миллионов строк кода, создано усилиями 200 программистов и имеет имя, вызывающее в памяти зимнюю дорогу в Миннесоте?
Ответ: Внутренний код для систем с RISC-процессором — SLIC (System Licensed Internal Code). Хотя, несомненно, придумавшие это имя разработчики имели в виду значение слова slick на сленге («чудесный», «замечательный», «первоклассный»), а не свойства зимних миннесотских дорог.
Когда в 1991 году в Рочестере начались работы над RISC-процессором, потребовалось внести множество изменений в LIC, расположенный под MI. Некоторые компоненты (но не все!) должны были быть полностью переработаны. Большая часть существующего LIC также требовала реструктуризации. Этот код уже претерпевал частые изменения и модернизации при создании новых моделей System/38 и AS/400.
Из-за множества изменений производительность работы программистов над этой частью системы уменьшалась, а расходы на сопровождение росли. Моральный дух наших программистов, постоянно латавших старый код, тоже падал.
До перехода на RISC-процессоры нам нужно было еще выпустить три новых версии VLIC, из-за чего мы не могли полностью переключиться на SLIC. Поэтому для создания новой ОС было решено создать специальное подразделение во главе с Майком Томашеком. Входившие в его состав инженеры могли выбирать любые методы разработки по своему усмотрению.
На совещании по выработке плана действий эта группа рассмотрела два подхода к модернизации LIC. Первый состоял в том, чтобы заново спроектировать и написать низкоуровневые компоненты, затронутые изменением процессора. Второй — переместить эти затронутые компоненты в аппаратуру RISC с минимальными изменениями. Данный тип миграции ПО без изменения логики работы программы часто называется переносом. Все остальные компоненты, не затронутые изменением процессора, такие как база данных, должны были быть перенесены с минимально возможными модификациями.
Майк и его команда решили перепроектировать и переписать затронутые компоненты заново. Это было нелегким решением, так как большая часть низкоуровневого кода основывалась еще на первоначальном проекте System/38 и интенсивно настраивалась для повышения производительности в течение 15 версий системного ПО. Не все верили в успех: ведь предстояло полностью изменить лишь «начинку» переписываемых компонентов, оставив в неприкосновенности все интерфейсы, чтобы не затронуть переносимые компоненты. Кроме того, надо было учесть возможность расширений ПО в планируемых новых версиях AS/400. В общем, все это напоминало стрельбу по движущейся мишени.
Билл Берг — один из десяти специалистов, рекомендовавших использовать PowerPC для AS/400, — продвигал идею сократить время разработки, использовав объектно-ориентированное программирование (ООП). Объектно-ориентированные языки приобрели популярность конце 80-х как способ быстрого создания программ и уже были достаточно совершенными, чтобы использовать их в таком большом проекте. Билл Армстронг (Bill Armstrong) и Дик Мастейн (Dick Mustain) — также твердые сторонники объектно-ориентированной разработки — были с ним согласны. Пол Мэттисон (Paul Mattison) собрал команду и подготовил план действий. Поддержка ключевых разработчиков также доказала, что новая технология программирования поможет обеспечить делу успех. Кроме того, мы собирались нанять новых людей.
Концепции объектно-ориентированного программирования
Давайте кратко рассмотрим основные элементы и термины ООП. Объект — это основной элемент программы, объединяющий в себе данные и операции над ними. Операция, которую может выполнить объект, иногда называется методом. Внутренняя структура данных и реализация методов объекта скрыта от остальной программы. Это называется инкапсуляцией. Программе доступен только интерфейс объекта. ООП отличается тем, что объединяет операции и данные воедино (при процедурном программировании операции отделены от данных).
Подход ООП предполагает повторное использование ПО. Основной механизм обеспечения повторного использования — класс, представляющий собой шаблон, описывающий все объекты, для которых характерны одинаковые операции и элементы данных. Следовательно, может быть создано много объектов каждого из классов. Часто они называются экземплярами объекта.
Для существующего класса можно создать подклассы путем использования наследования. Наследование позволяет программисту и создавать новые подклассы, и повторного использовать код, а также данные базового класса без их повторения. Вновь полученные подклассы настраиваются так, чтобы соответствовать конкретным потребностям приложения. Способность подклассов одного класса отвечать на одно и то же входящее сообщение по-разному называется полиморфизмом. Полиморфизм объединяет концепции наследования и динамического связывания (dynamic binding).
Наборы объектов, созданные из классов и подклассов, могут быть объединены для построения необходимых сервисов ОС. После определения достаточно сложного набора классов (называемого библиотекой классов), программисты могут использовать классы этого набора, а не программировать заново функции, предоставляемые классами.
Однако в объектно-ориентированной технологии есть и недостатки. Производительность ядра ОС чрезвычайно важна, так как сильно влияет на производительность системы в целом. Исследования приложений для AS/400 показали, что значительная часть длинных цепочек команд приходится на код ОС. А при применении объектно-ориентированной технологии для некоторой функции повторно используется большое число маленьких модулей, и общая длина цепочек команд увеличивается, по сравнению с реализацией той же функции как единого целого. Группе пришлось включить в план работ время для выполнения тонкой настройки таких функций, чтобы сохранить показатели производительности ядра, достигнутые за предшествующие годы его разработки.
Среда разработки SLIC
Группа разработчиков должна была выбрать язык программирования. Язык программирования VLIC, называвшийся PL/MP и использовавшийся со времен разработки оригинальной System/38, был основан на языке PL/I. MP в его названии расшифровывается как Machine Product — имя, которое часто использовалось для обозначения аппаратных средств и обоих слоев микрокода. Компилятор PL/MP, как и ассемблер IMPI, генерировал двоичные машинные команды IMPI.
Язык PL/MP не пригоден для ООП, но его по-прежнему использовали для тех компонентов, которые не переписывались. А для остальных был разработан новый компилятор PL/MP, генерировавший двоичный код для PowerPC. Кроме того, было создано специальное средство переноса программ, которое сканировало код, отыскивая зависимости от IMPI, прежде чем преобразовать его в новый PL/MP.
В течение ряда лет мы пытались использовать другие языки при разработке компонентов VLIC. Например, один из наших новейших трансляторов был написан на Modula-2, применялся также язык С. Однако, мы чувствовали, что ни один из них не подходит для проекта, основанного на объектно-ориентированной технологии. Выбор напрашивался сам собой — язык C++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера.
Другим преимуществом С++ была возможность легко найти людей, его знающих. Для этого проекта нам было нужно много новых программистов, и начался массовый найм. Скоро над проектом SLIC работало более 200 человек.
Для успеха проекта обучения было крайне важно, чтобы вновь набранные сотрудники поскорее изучили внутреннее устройство AS/400, а наши старые работники — программировать на С++. Некоторые уже умели это, но большинство из них использовали С++, как улучшенный С. Нужно было научить каждого объектно-ориентированному подходу. Это стало настоящей проблемой, так как в Рочестере на тот момент не оказалось никого, кто зашел бы дальше прочтения нескольких книг по данной теме. Решение было предложено Крисом Джонсом. Согласовав свои действия с другими руководителями проекта, он нашел стороннего консультанта — эксперта как в объектно-ориентированной технологии, так и в программировании на С++. Никогда ранее мы не обращались «на сторону» по подобным поводам. У IBM были внутренние программы обучения, и персонал, который этим занимался. Разумеется, приглашение на работу чужака было воспринято в штыки. Крис настаивал и убедил-таки руководство нанять консультанта для интенсивного шестинедельного обучения наших сотрудников. Мы даже специально выгородили прямо посередине отдела разработки классную комнату, которая использовалась исключительно для обучения.
Возможность повторных итераций при разработке — фундаментальное преимущество ООП, но при ее использовании трудно оценить, в какой степени мы продвинулись вперед. Прием, который мы использовали для «измерения прогресса», заключался в так называемых BUB (Bring up Bind). Каждый BUB представлял собой группу объектов, реализовывавших четко определенный набор функций ОС, и имевшую общий интерфейс с другими компонентами. Путем сравнения BUB с другими компонентами, мы могли оценить, как продвигается разработка. Кроме того, BUB позволили нам действовать в определенном порядке, а также вызвали переделку известного рекламного лозунга Budweiser: «This BUB's for you».
Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов. Считая весь перенесенный код, ниже MI работает более 3 миллионов строк кода ОС.
Затраты на разработк у 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»), что, впрочем, практиковалось в Рочестере и раньше. Мы использовали такой трюк для разработки систем, которые не считались стратегическими и, таким образом, не финансировались централизованно. Вспомните, что и сама 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 (интерфейс эмуляции независящий от технологии)
Приняв решение использовать для выполнения набора команд 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 старое изречение: «Целое больше, чем простая сумма частей».