Текст книги "Основы 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)[ 27 ]27
  Многие годы меня мучили вопросами о смысле названий горизонтальный и вертикальный. Так вот, смысла в них не много. Нам нужны были названия, чтобы как-то различать эти два слоя, и мы вспомнили, что в начале 70-х микрокод для некоторых System/370 подразделялся на горизонтальный и вертикальный. Обычно на машинах с горизонтальным микрокодом процессор мог выполнять несколько операций в одном цикле, а на машинах с вертикальным микрокодом . только одну. И если называть нижний слой горизонтальным микрокодом отчасти справедливо, то слой VMC определению вертикального микрокода никак не удовлетворяет.


[Закрыть]. Самым низким уровнем был 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 на сленге («чудесный», «замечательный», «первоклассный»), а не свойства зимних миннесотских дорог[ 28 ]28
  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 показали, что значительная часть длинных цепочек команд приходится на код ОС. А при применении объектно-ориентированной технологии для некоторой функции повторно используется большое число маленьких модулей, и общая длина цепочек команд увеличивается, по сравнению с реализацией той же функции как единого целого. Группе пришлось включить в план работ время для выполнения тонкой настройки таких функций, чтобы сохранить показатели производительности ядра, достигнутые за предшествующие годы его разработки[ 29 ]29
  Оптимизация кода LIC продолжалась долгие годы после создания первого ядра RISC. В результате при выходе версии V3R7 на рынок, некоторые покупатели отметили 50-процентный рост производительности. После выпуска V4R1 на некоторых конфигурациях системы был отмечен новый рост производительности без необходимости замены аппаратуры. Настройка ядра любой ОС – это бесконечный процесс.


[Закрыть].

Среда разработки 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++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера[ 30 ]30
  Дик Бэйнс любит сравнивать языки программирования с куском мыла. Например, он говорит, что программирование на RPG напоминает попытку отрезать кусок мыла пластмассовой ложкой. Программирование же на С+ + похоже, по его мнению, на отрезание того же куска с помощью обоюдоострой бритвы: можно быстро делать очень точные разрезы, но по окончании процедуры все мыло будет в крови.


[Закрыть].

Другим преимуществом С++ была возможность легко найти людей, его знающих. Для этого проекта нам было нужно много новых программистов, и начался массовый найм. Скоро над проектом SLIC работало более 200 человек.

Для успеха проекта обучения было крайне важно, чтобы вновь набранные сотрудники поскорее изучили внутреннее устройство AS/400[ 31 ]31
  Значительная часть этой книги была первоначально написана мною как раз для их обучения.


[Закрыть], а наши старые работники – программировать на С++. Некоторые уже умели это, но большинство из них использовали С++, как улучшенный С. Нужно было научить каждого объектно-ориентированному подходу. Это стало настоящей проблемой, так как в Рочестере на тот момент не оказалось никого, кто зашел бы дальше прочтения нескольких книг по данной теме. Решение было предложено Крисом Джонсом. Согласовав свои действия с другими руководителями проекта, он нашел стороннего консультанта – эксперта как в объектно-ориентированной технологии, так и в программировании на С++. Никогда ранее мы не обращались «на сторону» по подобным поводам. У IBM были внутренние программы обучения, и персонал, который этим занимался. Разумеется, приглашение на работу чужака было воспринято в штыки. Крис настаивал и убедил-таки руководство нанять консультанта для интенсивного шестинедельного обучения наших сотрудников. Мы даже специально выгородили прямо посередине отдела разработки классную комнату, которая использовалась исключительно для обучения.

Возможность повторных итераций при разработке – фундаментальное преимущество ООП, но при ее использовании трудно оценить, в какой степени мы продвинулись вперед. Прием, который мы использовали для «измерения прогресса», заключался в так называемых BUB (Bring up Bind). Каждый BUB представлял собой группу объектов, реализовывавших четко определенный набор функций ОС, и имевшую общий интерфейс с другими компонентами. Путем сравнения BUB с другими компонентами, мы могли оценить, как продвигается разработка. Кроме того, BUB позволили нам действовать в определенном порядке, а также вызвали переделку известного рекламного лозунга Budweiser: «This BUB's for you»[ 32 ]32
  Дословный перевод: «Эта бутылка Будвайзера для Вас». – Прим. консультанта.


[Закрыть].

Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов. Считая весь перенесенный код, ниже MI работает более 3 миллионов строк кода ОС.