Основы AS/400

Солтис Фрэнк

 

Фрэнк Солтис

Той, кого люблю уже более 33 лет — моей жене Сандре.

 

От автора

Рочестер— пожалуй, самое творческое подразделение корпорации IBM. Далеко не все сотрудники IBM согласятся с таким утверждением. Разумеется, работа в маленьком городке на краю прерий на юго-востоке Миннесоты не означает полной изолированности от остальной корпорации, но все же создает сложности в части признания заслуг. Мы, сотрудники подразделения IBM в Рочестере, не часто получали право голоса при определении перспектив развития корпорации. Но изолированность имеет и свои преимущества. Самое большое из них — возможность сосредоточиться на нуждах наших заказчиков. Год за годом преданные своему делу люди из Рочестера продолжали творить, и год за годом результаты этого творчества приносили IBM прибыль. Рочестер никогда не достигал больших побед в «битве прожектеров» в штаб-квартире IBM, но мы всегда выходили победителями в битве за заказчиков.

Секрет успехов Рочестера — в его людях. Мы здесь, потому что нам это нравится. Нравится жить и работать в маленьком городе, где, как гласят рекламные щиты, «зимы холодны, а компьютеры горячи». Для многих из нас Рочестер — это не просто остановка в пути, но станция назначения. Наверное, именно поэтому мы с таким трепетом относимся к результатам своего труда.

В этой книге я стремился поименно вспомнить подвижников, чей самоотверженный труд сделал возможным успех AS/400 и ее предшественниц. Полностью эта задача практически невыполнима. Например, здесь не упомянуты многие лидеры разработки OS/400, так как в книге просто не хватило места для подробного рассказа об этой изумительной операционной системе. Кстати, такой рассказ вполне может лечь в основу отдельного издания. Я надеюсь, те, кого мне не удалось упомянуть, простят мне. За 34 года, проработанных в Рочестере, не было дня, когда бы я ни ощущал царящей там атмосферы творчества.

Конечно, наша работа не завершена. Во многих отношениях серия AS/400e — лишь первый шаг на новом пути, и еще далеко не удовлетворяет своих создателей. Книга Inside the AS/400 (первое издание), где было описано то новое, что было внесено при разработке версии 3, создавалась именно под этим углом зрения. В этом, втором, издании мы рассмотрим версию 4 и то, что будет после нее.

Замысел этой книги возник еще в 1985 году. Некоторые, в том числе Пол Конт (Paul Conte), написавший предисловие для обоих изданий, предлагали мне написать книгу о System/38 и истории этого проекта. С повторным рождением System/38 в виде AS/400 в 1988 году я начал писать книгу о разработке этих систем и людях, их создавших. С тех пор я постоянно исправлял рукопись. Пол и другие торопили меня с завершением «летописи», и просили поскорей поделиться историей Рочестера с остальным миром. Кое-что из той рукописи вошло в первое издание Inside the AS/400. Этот исторический экскурс имел столь положительные отклики, что я расширил его и включил как приложение в это, второе, издание.

В течение нескольких последних лет я с огромным удовольствием сотрудничаю с Duke Communications International (родительской компанией Duke Press и журнала NEWS/400). Дэйв Дюк (Dave Duke) и его сотрудники проделывают огромную работу по изданию журнала, книг и организации конференций. И когда пришла пора подыскивать издательство для этой книги, я, естественно, выбрал Duke Press. С самого начала со мной работал Дэйв Бернар (Dave Bernard), главный редактор Duke Press, благодаря которому и первое, и второе издание книги получились столь качественными.

Трудную работу редактора обоих изданий книги выполняла Шэрон Хэмм (Sharon Hamm). Ей приходилось обрабатывать бесконечные изменения, которые я вносил в рукопись, и в то же время удерживать меня и сотрудников издательства в рамках плана. Она прекрасно справилась с этой задачей. Спасибо, Шэрон; работа с тобой была удовольствием.

Над этим вторым изданием работала также Триш Фабион (Trish Faubion) — ведущий редактор Duke Press. В первый раз мне довелось сотрудничать с ней при написании статей для NEWS/400 (тогда она была ведущим редактором этого журнала). Триш занималась выпуском второго издания, составляла для нас план и помогала укладываться в него. Спасибо тебе, Триш, за твой вклад в создание этой книги.

Наибольший вклад в окончательное оформление обоих изданий внес был научный редактор Ричард Рубин (Richard Rubin). Ричард хорошо известен своими превосходными статьями, особенно в области проектирования баз данных. Я был склонен смотреть на AS/400 изнутри, Ричард же — с точки зрения пользователя. Всякий раз, когда я уносился в облака, прославляя какой-нибудь технический аспект AS/400, он спускал меня на землю вопросом: «Какой смысл это имеет для пользователя?» Благодаря тому, что Ричард почти везде настаивал на наличии примеров и проявлял внимание к деталям, текст стал гораздо понятнее широкому кругу читателей. Спасибо, Ричард.

Наконец, эта книга вообще не была бы написана без самого важного человека в моей жизни — Сандры, моей жены. Заметив мои затруднения в начале работы, Сандра помогала мне сортировать материалы и расшифровывать видеозаписи моих лекций по архитектуре AS/400. Эти расшифровки и составили черновой вариант книги. Во время работы над вторым изданием она продолжала играть роль «главного одобряющего», советчика, рецензента и редактора по совместительству. Спасибо тебе за то, что ты всегда была рядом.

Сандра и я — счастливые родители трех прекрасных сыновей: Майка, Брайана и Стива. Читателям первого издания известно, что мне вместе с сыновьями нравится водить гоночный Порше по дорогам Среднего Запада. Я сожалением должен признать, что Порше был самым заброшенным членом семьи в этом году. Всякий раз, когда я проходил мимо гаража, оттуда прямо-таки слышались его мольбы покататься. Раньше, когда я бывал слишком занят, эту обязанность принимали на себя мои сыновья. Но в этом году они тоже были слишком заняты собственными семьями и карьерой. Так что моей бедной машине оставалось лишь ждать, пока я закончу эту книгу. Но, что это? Я слышу доносящийся из гаража рев гоночного автомобиля. Кто-то зовет меня!

— F.S.

 

Предисловие

IBM AS/400 — одна из самых интересных по инженерным решениям и эффективных коммерчески компьютерных архитектур. Задолго до того, как термин «объектно-ориентированный» широко распространился, машинный интерфейс высокого уровня AS/400, появившийся в предшествовавшей ей System/38, предоставил разработчикам приложений набор объектов (таких как очереди, индексы и файлы базы данных), которые при создании программы можно было использовать в качестве строительных блоков. Объекты придали высоким функциональным возможностям системы согласованную и простую в работе форму. Унифицированный объектный интерфейс скрывает от программистов AS/400 детали, благодаря чему они могут игнорировать сложные управляющие блоки и системные процедуры, относящиеся к внутренним процессам операционной системы (ОС). Более того, с помощью набора заранее определенных операций ОС ограничивает доступ к объектам. Это обеспечивает приложениям дополнительную защиту при исполнении.

Объекты AS/400 расположены в слое программного обеспечения поверх аппаратных средств. Это позволяет IBM вносить в аппаратуру значительные изменения, не затрагивая при этом приложения. Обычно новое оборудование требует лишь обновления поставляемого IBM внутреннего кода — ведь интерфейсы объектов, задействованных приложениями, неизменны. Это еще одно преимущество объектов AS/400: они позволяют приложениям воспользоваться новшествами аппаратных средств, при этом модифицировать код приложений не требуется. Все детали реализации системных объектов «скрыты» слоем программного обеспечения.

Можно сказать, что архитектура AS/400 «балует» программистов — где еще Вы найдете подобную рациональность? И все же программисты любят знать, как работает системное программное обеспечение, и те, кто работает с AS/400 s не исключение. На любой конференции по AS/400 они обычно собираются группами и растолковывают друг другу, какова сущность внутренних процессов системы, что происходит при активизации программного объекта, переопределении файла при его открытии или выполнении какой-нибудь другой операции. Дело, конечно, не просто в неудовлетворенном любопытстве; во многих случаях глубокое понимание архитектуры AS/400 позволяет программисту писать более функциональный или эффективный код. Но любому опытному программисту известно, что только по руководствам всего не узнаешь. Это особенно справедливо для AS/400, руководства по которой специально лишены описания деталей внутренней структуры или функционирования.

Сокрытие деталей высокоуровневым машинным интерфейсом AS/400 повсеместно заслужило высокую оценку, и все же многие из нас давно ждали книги вроде этой — ясного и исчерпывающего описания важнейших компонентов архитектуры этой системы. Знакомство с ней необходимо любому программисту, пишущему для AS/400.

Конечно, мой интерес (я думаю, это относится и к другим разработчикам) не ограничивается только текущими техническими подробностями. Хочется больше знать и об истории такой совершенной системы, и о людях, давших ей жизнь, и, конечно, о перспективах AS/400.

Автор этой книги, Фрэнк Солтис — именно тот человек, кто действительно «изнутри» знает все это, и может компетентно рассказать о создании AS/400, использованных в ней технологиях и планах IBM. Сам Фрэнк — одна из центральных фигур повествования: с момента появления замысла System/38 он играл ключевые роли в эволюции архитектуры AS/400. Его опыт охватывает несколько основных эпох организационного и технологического развития IBM, ему приходилось отвечать и за аппаратуру, и за программное обеспечение и за организационные вопросы. Фрэнк сочетает в себе таланты инженера и системного архитектора, да к тому же сделал академическую карьеру в области информатики. Добавьте к этому незаурядный миннесотский юмор, и вот результат s чтение разделов, посвященных, к примеру, «тегированной памяти» или «очереди распределения задач», становится захватывающим.

Сейчас, когда мы переживаем бум Интернета, Web-узлов, языка Java и распределенных вычислений, очень интересно узнать, какие новые возможности AS/400 позволяют ей претендовать на роль «лучшего из серверов». В этом, втором, издании своей книги Фрэнк объясняет, каким образом новая архитектура RISC, а также существенные усовершенствования в OS/400 и SLIC (System Licensed Internal Code) позволяют обеспечить дополнительные возможности и лучшее соотношение цена/производительность для всего модельного ряда AS/400 — от систем начального уровня до мощных кластеров, обрабатывающих миллионы транзакций в час. Поистине, нет человека, который мог бы сделать это лучше.

Я впервые встретился с Фрэнком в 1985 году. Тогда я только что познакомился с System/38 после многих лет работы на мэйнфреймах IBM, и эта система была для меня новой и интересной. Фрэнк произвел на меня впечатление обычного «IBM'ера» — он часами рассуждал о технических деталях архитектуры, уделяя при этом большое внимание «человеческому фактору». Он был таким интересным и толковым рассказчиком, что я принялся убеждать его написать об System/38 книгу. Позднее я узнал, что именно тогда руководству IBM, будущее System/38 представлялось весьма туманным. Понятно, что Фрэнк не хотел рассказывать историю, пока не убедился, что у нее будет счастливый конец. Теперь же огромный успех AS/400, широта ее распространения и ключевая роль в стратегии IBM позволяют Фрэнку поделиться своими знаниями. Счастливого Вам путешествия по AS/400 с гидом, о котором можно только мечтать!

Пол Конт.

Президент, Picante Software, Inc.

 

Введение

 

Мы, представители компьютерной индустрии, часто с большой гордостью подчеркиваем, как много нам удалось сделать за относительно короткий период времени. Иногда мы даже хвастаемся, что осваиваем новые технологии быстрее, чем кто-либо еще. И все же, нельзя не упомянуть, что, хотя новое аппаратное и программное обеспечение порой действительно создается удивительно быстро, зачастую мы просто используем заново некоторые очень старые идеи.

Однажды бывший президент США Гарри С. Трумен (Harry S. Truman) сказал: «В мире нет ничего нового, за исключением истории, которой Вы не знаете». Чтобы до конца понять, как работает любая вычислительная система, необходимо изучить ее историю, а также понять людей, ее создавших. Особенно верно это для такой системы, как AS/400, которая, как мне кажется, не вписывается в общие рамки.

На дизайн вычислительной системы значительное влияние оказывает то, в рамках какой организации она была создана, и то, какие продукты ей предшествовали. Если группе разработчиков удалось нечто успешное, то на следующем цикле проектирования она «изобретет» это заново и вместо новой системы построит улучшенную модель существующей. Радикально новые идеи обычно приходят извне.

Возьмем проекты, создававшиеся на протяжении многих лет компьютерными фирмами восточного побережья США. Как правило, их ключевые концепции были заимствованы из исследований, выполненных в учебных заведениях типа Массачу-сетского технологического института MIT (Massachusetts Institute of Technology). В 60-х годах инженеры и ученые MIT под патронажем Министерства обороны США работали над проектом МШг^. Впоследствии и IBM, и другие компании нанимали выпускников этих университетов для создания новых операционных систем. Так как проектировщики имели сходный опыт, то и созданные ими системы оказались очень похожими. Такие операционные системы как ОС MVS для мэйнфреймов IBM, ОС VMS корпорации Digital Equipment и все ОС Unix — имеют общие «восточно-университетские» корни.

Даже новая ОС — Windows NT фирмы Microsoft — несет в себе черты того же самого прошлого. Команда, создавшая Windows NT, ранее работала над ОС VMS компании Digital, в результате многие элементы Windows NT «навеяны» VMS. Если Вы замените буквы аббревиатуры VMS на следующие за ними буквы английского алфавита, то получите WNT, и это не просто случайность. История AS/400 совершенно иная.

Менее года назад я был в Буэнос-Айресе на встрече с группой пользователей этой системы. По окончании встречи молодой репортер газеты «La Nacion» спросил меня: «Сформулируйте, пожалуйста, коротко причины того, почему в AS/400 столь много новшеств?». И я ответил: «Потому что никто из ее создателей не заканчивал MIT.» Заинтригованный моим ответом, репортер попросил разъяснений. Я сказал, что не собирался критиковать MIT, а лишь имел в виду то, что разработчики AS/400 имели совершенно иной опыт, нежели выпускники MIT. Так как всегда было трудно заставить кого-либо переехать с восточного побережья в 70-тысячный миннесотский городок, в лаборатории IBM в Рочестере практически не оказалось выпускников университетов, расположенных на востоке США. И создатели AS/400 — представители «школ» Среднего Запада — не были так сильно привязаны к проектным решениям, используемым другими компаниями.

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

 

Начало

В 50-х годах XIX века группа фермеров Новой Англии поселилась в Рочестере (Rochester), штат Миннесота. Вероятно, Рочестер и сейчас был бы маленьким сонным фермерским городком, если бы не торнадо 1883 года, от которого пострадали многие жители. Врач Уильям Уоралл Мэйо (William Worall Mayo), в то время гостивший здесь у приятеля, лечил раненых. Он так и остался в Рочестере, а позже к нему присоединились два его сына — Уильям в 1883 году и Чарльз в 1888. Принятое ими в 1889 году решение — открыть частную больницу, которую они назвали клиникой Мэйо, — превратило Рочестер, в конце концов, в международный медицинский центр. Сейчас здесь один врач на 70 жителей, чистая окружающая среда, замечательная система образования и низкий уровень преступности. По данным журнала «Money», Рочестер год за годом входит в двойку или тройку лучших мест страны для проживания.

А самое важное для нас то, что Рочестер — колыбель AS/400. В 1956 году IBM, в то время нью-йоркская компания с несколькими производственными и проектными филиалами в разных городах этого штата, объявила о создании нового подразделения в Рочестере. Томас Дж. Уотсон-старший (Thomas J. Watson, Sr.), основатель IBM, прожил большую часть жизни в Нью-Йорке и предпочитал размещать новые филиалы именно там. Решение выйти за пределы штата Нью-Йорк означало для IBM отказ от имиджа местной компании.

Впервые я приехал в Рочестер в 1962 году, за год до открытия там проектной лаборатории. Тогда я еще учился в университете, и IBM предложила мне работу на лето в Рочестере. В то время меня не привлекали ни компьютеры, ни тем более жизнь в маленьком степном городе на юге Миннесоты — я грезил авиакосмической индустрией Калифорнии. Но я был знаком с менеджером проекта в Рочестере и думал, что мне будет приятно поработать с ним летом.

По приезде я узнал, что работу над проектом уже получил другой человек. Мне предстояло работать над созданием банковского терминала. Я был разочарован, но согласился на этот вариант по той же причине, что заставляет других работать там, где им не нравится: я нуждался в деньгах.

Видимо, руководитель проекта банковского терминала знал, что я был разочарован, не получив работу над медицинским проектом. Он провел со мной очень много времени в разговорах о том, какую роль будут играть компьютеры в будущем Рочес-тера. И я поверил, что инженеры, в совершенстве владеющие навыками проектирования программного и аппаратного обеспечения, смогут здесь реализовать себя. В конце лета я вернулся в университет с вновь проснувшимся интересом к проектированию цифровых вычислительных систем.

Через год, окончив университет, я вернулся в Рочестер и стал работать под началом того же руководителя проекта. В течение следующих нескольких лет подразделение IBM в Рочестере перешло к разработке компьютеров, и я принял в этом участие. Затем, мне вновь предложили поучиться: я был одним из многих инженеров, имевших весьма ограниченные познания в области операционных систем. Недостаток знаний о вычислительных архитектурах и проектировании операционных систем я возмещал в Университете штата Айова (Iowa State University).

Я вернулся в Рочестер в конце 1968 года со степенью доктора и некоторыми вполне сложившимися идеями о том, как следует проектировать новую компьютерную систему. Вскоре, в июне 1969 года, был объявлен первый компьютер Рочестера

System/3. System/3 была продукцией специального назначения и более походила на счетную машину, чем на компьютер. Я не понимал тогда, что разработчикам из Роче-стера удалось попасть в компьютерный бизнес, лишь создав в штаб-квартире IBM иллюзию, что они делают счетную машину. В конечном счете это не сыграло большой роли, так как System/3 было суждено стать нашим первым успехом, залогом будущей революции в компьютерной индустрии.

В течение 1969 года я работал над проектом, в ходе которого мне удалось «отшлифовать» многие из идей, почерпнутых в университете. В конце 1969 года я получил новое задание — разработать архитектуру для наследника System/3.

 

Революция начинается

В пронизывающе холодный вторник 8 января 1970 года я представил руководству Рочестера предложения по революционно новой компьютерной архитектуре, основой которой был машинный интерфейс высокого уровня. Примененную в этой архитектуре структуру адресации, названную одноуровневой памятью, я позаимствовал и развил из собственной докторской диссертации. Основной мотив — защитить капиталовложения заказчиков в прикладные программы, сделав вычислительную систему независимой от нижележащих аппаратных технологий. Новая система должна была совершенно отличаться от System/3, но, несмотря на это, содержать большую часть функций последней. Эта способность поддерживать среду System/3 оказалась крайне полезной годы спустя, когда нам понадобилось соединить эти две линии.

Не испугавшись поистине радикальных идей, лежавших в основе новой архитектуры, руководство Рочестера решило принять эти предложения и создать специальную группу для разработки новой системы. В течение шести месяцев была создана группа из девяти человек, которая должна была превратить мечты в реальность. Я стал архитектором новой системы. Вряд ли я понимал тогда, что буду оставаться в этой роли более четверти столетия.

Подразделение Advanced Systems, сформированное для создания новой системы, действовало изолированно от разработки System/3 (семейство System/3 продолжало расти, и к нему добавились System/32 в 1975 году и System/34 в 1977). До середины 70-х новым проектом занималось не так уж много сотрудников, но затем сотни и тысячи людей со всей IBM присоединились к нашей команде. 24 октября 1978 года мы объявили о создании новой системы. Она была названа System/38.

System/38 была немедленно объявлена компьютером с расширенной архитектурой — одна из крупнейших инноваций IBM за долгие годы. Очень немногие люди, как внутри IBM, так и вне корпорации, по-настоящему поняли, что произошло. Но среди тех, кто осознал мощь и потенциал System/38, быстро сформировалось нечто, похожее на культ. Встречи групп пользователей часто походили на религиозные собрания.

Однако System/38 не заменила семейство System/3, как мы изначально надеялись. Новая система не привлекла многих наших старых заказчиков. Первые продажи System/38 были задержаны до июля 1980 года, как мы объявили, из-за недостаточной производительности. На самом деле, самая большая проблема производительности заключалась в том, что система не работала сколь-нибудь продолжительное время перед сбоем. Эта задержка отпугнула некоторых заказчиков. Кроме того, владельцы меньших систем — System/32 и System/34 — нашли, что новая система слишком велика и слишком дорога. Удовлетворить потребности большинства таких заказчиков смог объявленный в мае 1983 был последний вариант System/3 — System/36. Так что разработки компьютеров в Рочестере по-прежнему шли в двух разных направлениях.

 

Проект Fort Knox

В начале восьмидесятых IBM решила объединить пять ранее несовместимых линий продукции IBM, включая две из Рочестера, в новой интегрированной системе, названной Fort Knox. Ставилась цель: владельцы всех пяти типов машин должны были иметь возможность перенести свои приложения на эту единую систему. Разработка Fort Knox началась в четырех разных лабораториях IBM с больших инвестиций.

В 1985 году стало ясно, что проект Fort Knox зашел в тупик. У нас, в Рочестере, многие считали его нежизнеспособным с самого начала, так как он был призван разрешить проблемы IBM, а не потребителей. Было и такое мнение: проект слишком сложен технически, нет способа преобразовать пять разных систем в одну. И, кроме того, совместной работой четырех лабораторий управлять почти невозможно. По всем указанным причинам, Fort Knox потерпел неудачу, и IBM его закрыла.

Fort Knox «высосал» большинство ресурсов, которые иначе были бы направлены на System/36 и System/38. А без инвестиций трудно было поддерживать конкурентоспособность обеих систем. IBM зашла настолько далеко, что объявила System/38 «не стратегической» и не рекомендовала клиентам приобретать ее.

 

Ранняя AS/400 (она же System/38)

В конце 1985 небольшая группа разработчиков из Рочестера продемонстрировала, что на System/38 можно создать среду для программного обеспечения System/36. Стоимость оборудования снизилась настолько, что мы теперь могли создавать малые модели System/38. Это означало, что мы могли «закрыть» весь диапазон продукции Рочестера. Быстро последовало предложение: объединить две системы в одной машине, основанной на System/38. Мы назвали новую машину Silverlake и убедили руководство IBM, что можем ее создать.

Снова Рочестер показал IBM и всему компьютерному миру, на что способен. После беспрецедентного 28-месячного цикла разработки, мы объявили о новой, объединенной, системе под названием AS/400. Посвященные, однако, знали, что внутри каждой AS/400 скрывается System/38.

Успех AS/400 превзошел все ожидания. Очень быстро она не только «отвоевала» часть рынка, захваченную конкурентами в предыдущие годы, но и быстро обошла их всех. Ныне во всем мире работает более 500 000 систем AS/400, что делает ее бестселлером среди многопользовательских вычислительных систем. Культ System/38 стал полноценной религией.

В 1991 Apple Computer, Motorola и IBM достигли исторического соглашения по разработке нового семейства процессоров. Эти процессоры должны были использовать архитектуру RISC и применяться везде, от ручных устройств до суперкомпьютеров. Новые процессоры, названные PowerPC, были призваны потрясти компьютерный мир.

В это время Рочестер искал новую архитектуру процессора для следующего поколения AS/400. Это должен был быть первый полностью новый процессор по сравнению с 1978, использовавшимся в оригинальной System/38. И мы подумали: почему бы не объединить силы с альянсом PowerPC, чтобы создать для AS/400 новый процессор, основанный на этой архитектуре?

 

Союз AS/400-PowerPC

Я возглавлял в Рочестере группу, которая должна была определить требования к новому процессору для AS/400. Тогда мы вместе с архитекторами и разработчиками PowerPC пытались создать 64-разрядный процессор, основанный на архитектуре PowerPC. По нашему мнению, это должно было обеспечить успех AS/400 в следующем столетии.

Появление новых процессоров PowerPC, оптимизированных для AS/400 — веха в истории AS/400, демонстрирующая мощь ее архитектуры. Обычно производители компьютерных систем, планируя перевод своих компьютеров на новые архитектуры процессоров, испытывают смешанные чувства. Ведь тем самым они обрекают своих заказчиков на довольно большие неудобства. Чтобы воспользоваться преимуществами новых процессоров, прикладное программное обеспечение нужно перекомпилировать или переписать. Операционная система также должна быть переписана. В результате, большинство производителей неохотно используют новейшие процессорные технологии.

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

Часто задают вопросы: «Как появилась AS/400?», «Кто эти люди, называющие себя ее создателями?». Далее я постараюсь ответить на них.

 

Команда технических разработчиков

В IBM разработка любой новой продукции осуществляется командой, каждый из участников которой вносит в дело свой вклад. По правде говоря, успех проекта обычно определяют всего несколько человек. Это инженеры и администраторы — лидеры, обладающие предвидением, творческими способностями и энергией. Своим созданием и успехом как System/38, так и AS/400 обязаны именно таким людям.

В Рочестере много хороших инженеров и администраторов, но лишь несколько истинных провидцев. Дальновидный лидер способен не только сознавать перспективы проводимых работ, но и донести свое видение до других. Затем идея начинает жить собственной жизнью, и приобретать некие реальные очертания. Теперь дело лидера — поощрение тех, кто старательно и успешно работает над различными частями проекта.

В 1972 году я по-прежнему все еще пытался увлечь наших разработчиков радикальными концепциями архитектуры System/38. Большинство технических специалистов успешно трудились над созданием новой аппаратуры, «не ведая, что творят». Они полагали, что просто разрабатывают некое новое программное обеспечение для уже существующей системы. (Формат внутренних команд System/38 был очень похож на используемый в System/370.) Это был единственный способ задействовать людей так, чтобы они чувствовали себя комфортно, не подозревая, что делают нечто необычное.

Прорыв на фронте программного обеспечения тогда достигнут не был. Большинство программистов в Рочестере написали улучшенные версии программного обеспечения System/3. Они чувствовали себя вполне комфортно и не желали никаких революций в области архитектуры.

Именно в это время на передовую линию создания полной архитектуры вышли два человека. Они помогли мне убедить все сообщество разработчиков в том, что мы находимся на правильном пути. Дик Бэйнс (Dick Bains) и Рой Хоффман (Roy Hoffman) — одни из наиболее творческих, обладающих истинным даром предвидения людей, которых я когда-либо встречал. Они также отличаются истинной преданностью идее. В течение 1972 мы втроем завершили спецификацию архитектуры AS/400, и хотя в последующие годы некоторое детали претерпели изменения, в целом концепция осталась неизменной.

У Дика — талант в области технологии компиляторов и языков. Его опыт стал решающим при определении машинного интерфейса высокого уровня и внутреннего транслятора.

Дик вырос в соседнем штате Висконсин, до начала работы на IBM в Рочесте-ре, попробовал себя в нескольких ролях, одно время даже был инструктором по лыжам в Эспине (Aspen), штат Колорадо. И всякий раз, когда при разработке спецификации архитектуры у нас возникали затруднения, он начинал вздыхать по более легкой жизни лыжного инструктора. По счастью, Дик не поддался этому стремлению.

Дик каждый раз так увлекался решением проблемы, что мог действовать, не задумываясь о последствиях. Например, годом ранее, он пытался убедить руководство в несовершенстве защиты некоторых местных компьютерных систем. Когда никто не захотел его слушать, Дик решил продемонстрировать проблему наглядно. Войдя в систему, допуска к которой он не имел, он оставил там сообщение с предложением позвонить ему, если те, кто несет ответственность за защиту системы, захотят закрыть «дыру». При этом он умудрился нечаянно попортить несколько файлов. Вся эта история чуть не стоила Дику места, но к счастью для всех нас, руководство признало его талант и он не был уволен. Более того, ему удалось доказать свою правоту.

До сего дня Дик сохранил те же качества. Когда он считает, что что-либо должно быть сделано, то формальности его не останавливают; он берет и делает это. Широта знаний по AS/400 и способность решать технические и коммерческие проблемы в контакте с заказчиками делают его очень ценным специалистом. Он остается одним из технических лидеров работ по AS/400.

У Роя уже в те времена был накоплен солидный опыт в области компьютерных архитектур и проектирования операционных систем. Его вклад в разработку архитектуры System/38 — особенно в области низкоуровневых функций операционной системы — обеспечил ей успех.

Рой вырос на ферме неподалеку от Рочестера. Как и многие молодые люди, он рано покинул дом, чтобы иметь возможность учиться в колледже и работать. Какое-то время он работал на другую компьютерную компанию, но, получив докторскую степень, вернулся в Рочестерское подразделение IBM. По выходным Рой гоняет по окрестностям на мотоцикле. У нас были долгие дискуссии о сравнительных достоинствах мотоциклов и спортивных машин (я всегда предпочитал, чтобы у меня над головой была какая-то крыша или перекладина).

Рою нет равных в решении технических проблем. Его познания в области вычислительных систем огромны, он способен атаковать проблему с позиций, недоступных большинству из нас. Его свежий взгляд часто помогал найти красивое техническое решение. (На самом деле Рой пошел дальше. Он часто давал окружающим и личные советы, нужны они нам были или нет. Меня по-прежнему забавляет, с каким удовольствием он стремится проанализировать ситуацию и дать мне какой-нибудь дикий совет по воспитанию детей или по другому предмету, в котором абсолютно несведущ.) После завершения работы над System/38, Рой возглавлял некоторые передовые технические проекты Рочестера. Он также работал над новыми технологиями для всей IBM. Рой был членом IBM Academy, где помогал определять направления технического развития всей корпорации. В 1994 году Рой ушел на пенсию. Сейчас он как раз закончил книгу о сжатии данных, и в погожие дни Вы по-прежнему можете увидеть, как он гоняет на своем «Харлей-Дэвидсоне».

Не ясно как, но этот союз лыжного тренера, «рокера» и автомобильного фаната достиг успехов в компьютерной области. К концу 1972 разработка новой архитектуры была завершена. В последующие годы Дик, Рой и я часто собирались для обсуждения изменений и новых идей. До настоящего дня я удивляюсь, как много из того, что мы совместно вложили в систему, другие открывают только сейчас.

Рочестеру повезло со специалистами. В пользу этого суждения говорят многие инновации как в аппаратном, так и в программном обеспечении. Однако никто другой не обладал таким видением системы и ее перспектив, как Дик и Рой. И как и очень многие другие узкие специалисты, чья работа не видна непосвященным, эти двое никогда не получали того признания, которое заслужили.

 

Команда менеджеров

Ни одна система не «пойдет» только благодаря удачному инженерному решению; без хорошего управления тоже не обойтись. На мой взгляд, успех System/38 и AS/400 обеспечили пятеро менеджеров, лучше других увидевшие их перспективы. Но один из пяти заслуживает признания более, чем остальные: Гарри Ташиян (Harry Tashjian). Это он, осознав потребность в небольшой, простой в использовании деловой системе, и создал новый рынок для компьютеров. Без его дара предвидения не было бы успеха наших компьютеров.

Гарри был главной организующей силой проектов System/3, System/32, System/34, System/36 и System/38. Сначала он выполнял функции системного менеджера (system manager) всех этих продуктов, позднее стал директором Рочестерской лаборатории. Именно благодаря Гарри крошечное подразделение IBM, затерянное среди кукурузных полей Миннесоты, стало мировым лидером в разработке деловых компьютерных систем.

Гарри Ташиян — тот самый менеджер проекта банковского терминала, много лет назад склонивший меня к работе с компьютерами. До сих пор помню наши долгие разговоры о потенциале Рочестера в разработке новых вычислительных систем. Гарри «благословил» меня на новое путешествие в университет для изучения компьютерных архитектур, а когда я опять вернулся в Рочестер, именно он назначил меня на разработку архитектуры System/38, которой суждено было превратиться в AS/400, и обеспечил мне поддержку. Без Гарри AS/400 не было бы.

Успех System/38 обеспечили еще два менеджера. Рей Клотц (Ray Klotz) был нашим техническим менеджером (engineering manager) и моим боссом на протяжении большей части проекта. В 1970 году Гарри поручил Рею создать команду из 9 человек. Хорошо разбираясь в аппаратном обеспечении, Рей курировал создание процессора System/360 в Эндикотте (Endicott), штат Нью-Йорк, прежде чем пришел в Рочес-тер, чтобы возглавить разработку аппаратуры System/3.

Сначала Рей относился к System/38 сдержаннее, чем многие из нас. Он иногда напоминал, что все аппаратное обеспечение System/3 насчитывало лишь 3 000 цепей, и спрашивал, почему нам нужно настолько больше. Он продолжал сомневаться в наших технических решениях до тех пор, пока не приходил к убеждению, что мы рассмотрели все возможные варианты. Затем он давал нам «карт-бланш». Всякий раз, когда мы испытывали трудности, он был рядом, чтобы поддержать и помочь найти выход.

Для большинства из нас Рей был кем-то вроде отца. Мы все вздрагивали, когда он повышал голос, что бывало часто. Он требовал от каждого из нас безупречной работы и обычно добивался своего. Но за грубоватой внешностью Рея скрывался удивительно тонкий человек.

Из всех моих знакомых Гейлорд Гленн Хенри (Gaylord Glenn Henry) — самый выдающийся и совершенно неистовый менеджер.

Сказать, что Гленн не вполне вписывался в образ типичного, консервативного менеджера IBM, — не сказать ничего. Неряшливая борода, часто нелепая одежда и неизменные упаковки по шесть розовых банок какой-то диетической «шипучки» свидетельствовали о том, что перед Вами незаурядная личность.

В 1972 году Гленн перешел к нам из лаборатории IBM в Бока Ратон (Boca Raton), штат Флорида, и стал менеджером по программированию (programming manager) для System/32, а затем и System/38. Сильный и целеустремленный человек, он вдохновлял окружающих, увлекал за собой как разработчиков, так и администраторов. Когда нам казалось, что возникшая проблема непреодолима, Гленн убеждал нас, что все держит под контролем. Вскоре как-то само собой появлялось решение, а Гленн лишь улыбался. Без его таланта и дальновидности разработка System/38 могла быть прекращена множество раз.

Я еще не упомянул о соревновании по крепости голосовых связок между ° о Гленном и Реем. Если они не были согласны друг с другом, стены дрожали.

Было истинным удовольствием наблюдать за их спорами, особенно зная, что I ни тот, ни другой не понимают по-настоящему того, за что ратуют. Иногда к их спору присоединялся Гарри, но чаще он позволял Гленну и Рею улаживать свои разногласия самостоятельно. Однако все были согласны между ■ собой в одном: мы собираемся создать вычислительную систему, лучшую из когда-либо существовавших в мире. Наградой этим волевым личностям стала System/38.

К сожалению, после окончания работ над System/38 мы расстались с этими людьми. Гарри Ташиян оставил Рочестер, чтобы возглавить создаваемую IBM новую компанию — Discovision. После этого он занимал в IBM другие руководящие посты, прежде чем ушел на пенсию, имея 38 лет стажа.

Гленна перевели в Остин (Austin), штат Техас, где он возглавил разработку PC-RT. Он оставил IBM в 1988 году после 21 года работы, возмущенный неспособностью организации воспринимать новые идеи. Не удивительно, что некоторые из этих идей только сейчас реализованы в продукции IBM. Убежден, что уход Гленна был большой потерей для корпорации.

Но печальней всего была утрата Рея. Он умер вскоре после объявления System/38 и так и не узнал, чем стала его система для всего компьютерного мира. Никто и никогда не сможет занять его место.

 

В последнюю минуту

В начале 80-х годов из-за недальновидного руководства развитие вычислительной техники Рочестера стало спотыкаться. Однако у нас все еще было несколько хороших менеджеров, понимавших значение создаваемых систем. Этим людям приходилось поддерживать жизнь наших проектов зачастую весьма хитрыми способами. Казалось, у нас нет перспектив, и наши позиции на рынке окончательно будут завоеваны конкурентами. По счастью, в последнюю минуту появился человек, спасший Ротчестер от глубокого забвения. Его звали Том Фьюри (Tom Furey).

Том всегда был отличным продавцом. Он знал работу IBM изнутри и ухитрился убедить руководство, что системы Рочестера имеют стратегическое значение для будущего корпорации. Затем он начал «накачивать» нас приложить все мыслимые усилия и еще чуть-чуть, чтобы выпустить новую систему в рекордно короткие сроки.

Том хорошо знал рынок и требования заказчиков. Он преобразовал Рочестер из организации, управляемой техническими идеями, в организацию, движимую требованиями рынка. Прежде всего, он добился, чтобы наши заказчики были напрямую вовлечены в разработку. Совещания пользователей играли важную роль при выборе вариантов проектирования, а в результате получилась система, которую многие из них чувствовали своей. Позднее, Рочестер выиграл престижную премию Malcolm Baldrige National Quality Award за эту разработку.

Часто по-настоящему оцениваешь человека, лишь вглядываясь в него из будущего. Том никогда не был силен по части техники, как некоторые из его предшественников, и многие в лаборатории не принимали его как лидера, под тем предлогом, что Том до конца не может проникнуть в суть того, что они делают. Он и не мог, ну и что? Например, Том никогда не понимал, что AS/400 — это переупакованная System/38; а если и понимал, то никому не говорил об этом. Зато он убеждал всех и вся за пределами Рочестера, что это совершенно новая система, и ему верили.

Своим скорым коммерческим успехом AS/400, несомненно, обязана Тому. Он организовал массированный выход на рынок этого продукта IBM в масштабах, беспрецедентных со времен System/360. В итоге AS/400 выдвинулась на передние позиции среди коммерческих многопользовательских систем. После Рочестера Том перебрался в Санта-Терезу (Santa Teresa), штат Калифорния, где занял должность генерального менеджера разработки базы данных IBM DB/2. Позднее он стал генеральным менеджером IBM по клиент-серверным системам. Сегодня Том возглавляет проекты IBM, связанные с Олимпийскими Играми.

 

Твердая рука

После перехода Тома на новую работу в Калифорнии, мы потеряли значительную часть рынка. Несмотря на то, что нам досталась награда Malcolm Baldrige National Quality Award за учет требований рынка, руководство лаборатории тянуло нас назад к работе, ориентированный на удачные технические, но не коммерческие решения. Совещания заказчиков прекратились, а вместе с ними и прямой вклад пользователей в проектирование, чего удалось добиться Тому. Наше новое руководство состояло из бывших разработчиков и чувствовало себя не в своей тарелке, когда пользователи вмешивались в принятие проектных решений.

Единственным замечательным исключением на общем печальном фоне была наша программа Partners in Development (PID). Ей занималась группа энтузиастов, первоначально под руководством Джима Келли (Jim Kelly). Их усилия сосредоточилась на поддержке сообщества бизнес-партнеров AS/400 во всем мире, которые занимались разработкой и продажей большей части прикладного ПО, использовавшегося нашими заказчиками. Эти люди заслуживают самой большой похвалы за наш успех в данной области.

Подразделение AS/400 не утратило ориентированности на рынок благодаря еще одному человеку — Биллу Цайтлеру (Bill Zeitler). Билл был помощником генерального менеджера по маркетингу примерно с момента выхода первой системы до конца 1995 года, когда он получил назначение в Азию на 15 месяцев. За эти годы до момента временного ухода Билла в нашем подразделении сменилось пять генеральных менед-жеров5. Каждый из этих руководителей внес определенный вклад в успех AS/400, но именно твердая рука Билла направляла наш корабль в бурных водах рынка.

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

Так что без Билла и его команды AS/400 не смогла бы занять свое нынешнее положение на рынке. По счастью, по окончании командировки в Азию, Билл возвратился к нам в качестве генерального менеджера, чтобы запустить в разработку серию AS/400е.

 

Зачем написана книга?

Никогда прежде IBM не освещала так глубоко и всесторонне историю проектирования и особенности архитектуры AS/400. Никогда не объяснялось, как этой замечательная система делает то, что она делает. Моя задача — снять с AS/400 завесу тайны, а также пролить некоторый свет на то, как система создавалась.

Вы, возможно, уже поняли, что я чувствую себя обязанным включить в книгу кое-какую историческую информацию. Несколько лет назад я неформально унаследовал пост историка Рочестера от Карла Гебхардта (Carl Gebhardt), занимавшего его изначально. Карл был бизнес-менеджером (business manager) наших ранних систем, а позже, в бытность Гарри Ташияна директором лаборатории, работал системным менеджером и System/34, и System/38. Карл отвечал за финансовый успех ранних систем Рочестера. Я работал у него в начале 80-х, когда Карл был нашим директором по стратегии (director of strategy). Долгие годы Карл был историографом Рочестера. Он часто так и представлялся (официально такого поста не было, но мы оба считали, что он должен быть). Если возникал вопрос о чем-нибудь, что произошло несколько лет назад, Карл в большинстве случаев знал на него ответ. Когда Карл оставил работу, мы обсуждали, кто должен занять этот почетный пост, и он сдал вахту мне.

Эта книга написана для тех, кто хочет узнать больше об AS/400. Это не спецификация для проектировщиков операционной системы, которым нужно гораздо больше деталей, чем здесь приведено; и не переделка рекламных материалов IBM. Она написана для пользователей, разработчиков приложений и студентов, которые хотят понять, как работает AS/400, чтобы достичь успеха в бизнесе, писать лучшие приложения или просто удовлетворить здоровое любопытство. Волшебство это или просто удачный проект? Возможно и то, и другое.

Хочу подчеркнуть: я излагаю в книге свою точку зрения. Я откровенный фанатик AS/400. Мои взгляды не обязательно совпадают с официальными позициями корпорации IBM. Надеюсь, чтение книги доставит Вам такое же удовольствие, как мне — ее создание.

 

Замечания ко второму изданию

Когда в 1994 году была объявлена Advanced Series, в Рочестере также выпустили первую версию новой операционной системы, которую назвали версией 3 V3R1 (Version 3 Release 1). Мы заявили, что собираемся изменить архитектуру процессоров на RISC, но системное ПО для обоих архитектур останется функционально эквивалентным, чтобы упростить переход под RISC. В 1995 году вместе с первыми RISC-моделями мы представили V3R6, которая должна была обеспечить функциональную совместимость с V3R1. В 1996 году появились расширенные версии обоих этих ПО: V3R2 и V3R7. Таким образом, Version 3 может рассматриваться как промежуточная операционная система на период перехода пользователей на новые RISC-модели.

Выход серии AS/400е в 1997 году вместе с OS/400 версии 4 (V4) был вехой, означающей конец периода перехода на RISC. Выпуски этой новой версии (V4R1, V4R2, V4R3 и т. д.) будут работать только RISC-моделях AS/400. Конкретно, OS/400 V4 работает на некоторых моделях Advanced Series (RISC-моделях) и на всех моделях серии AS/400e.

Если внешние интерфейсы RISC и не-RISC систем очень похожи, то этого нельзя сказать об их внутреннем устройстве. Некоторые внутренние компоненты одинаковы, другие же сильно отличаются. В этой книге, описывающей внутреннее устройство AS/400, невозможно полностью рассмотреть оба дизайна; для этого потребовалось бы две разные книги. Но вместо того, чтобы просто рассматривать только RISC-системы, я решил, там где это имеет смысл, также описать и некоторые подробности устройства не-RISC систем. Такое решение вызвано двумя причинами:

Понимание работы некоторых компонентов не-RISC систем поможет понять, почему мы решили перейти на RISC. Например, основным фактором, заставившим нас отказаться от оригинальной не-RISC архитектуры, была структура адресации. В главе 8 я рассмотрю как старую, так и новую систему, и постараюсь обосновать, почему изменения были необходимы.

Многие части не-RISC систем по-прежнему имеют значение: либо их компоненты будут перенесены в будущие проекты, либо переход на новый дизайн только начался. Примером последнего служит ввод-вывод, новая архитектура которого только начала создаваться (подробнее об этом — в главе 10).

Во всех случаях, я пытался ясно указать, где обсуждаются решения для RISC, а где нет. Теперь о содержании книги:

Глава 1 посвящена идеям, лежащим в основе расширенной архитектуры AS/400. Здесь также обсуждается интеграция и ее значение для заказчиков.

В главе 2 рассматривается самый низкий уровень системы AS/400 — архитектура процессора. В этой главе обсуждаются только RISC-процессоры (в том числе и то, как они появились).

В главе 3 дается описание внутреннего системного ПО AS/400, известного как System Licensed Internal Code (SLIC), и опять только RISC-систем.

Тема главы 4 — машинный интерфейс MI. MI практически одинаков и для RISC- или для не-RISC-систем, но я включил в свой рассказ описание дополнительных команд для RISC-систем.

Глава 5 посвящена объектам AS/400 и управлению ими. Все, что сказано здесь, применимо и к RISC-, и к не-RISC-системам.

В главе 6 описывается интегрированная реляционная база данных AS/400 и внутренняя структура системы.

Глава 7 посвящена защите от несанкционированного доступа, включая становящуюся все более важной защиту в сетях.

В главе 8 рассматривается одноуровневая память AS/400. Основное внимание уделено реализации для RISC-систем, но я включил в текст достаточно информации о варианте для не-RISC, чтобы обосновать необходимость произведенных изменений.

В главе 9 описана структура управления процессами AS/400. Большая часть сведений применима как к RISC-, так и к не-RISC-системам.

Глава 10 посвящена системе ввода-вывода. Вначале рассматривается существующий ввод-вывод для не-RISC систем, затем — изменения в структуре ввода-вывода, реализованные в серии AS/400е.

Глава 11 переходит от рассмотрения отдельных компонентов системы к расширениям версии 4, а также тем, которые могут появиться в ближайшем будущем. Значительная часть обсуждения версии 4 посвящена электронному бизнесу, так как он имеет наибольшее влияние на будущий дизайн AS/400.

Наконец, в главе 12 мы попробуем предугадать, что ожидает AS/400 в следующем столетии.

В дополнение к обсуждению каждого компонента и его взаимодействия с другими я объясняю, как эти компоненты были созданы, и чем они улучшают среду приложений. В конце концов, AS/400 предназначена именно для приложений и освоения с помощью новейших из них мира электронного бизнеса.

OS/400 версии 4 и аппаратура серии AS/400e — наш взгляд на то, как лучше использовать возможности интеграции AS/400 в электронном бизнесе. Под электронным бизнесом мы понимаем безопасный, гибкий и интегрированный подход, принятие решений с помощью комбинации систем и процессов, исполняющих базовые деловые функции. Простоту и доступность такого нового подхода к делу обеспечивают технологии Интернета и World Wide Web (WWW).

По началу использование серверов WWW в бизнесе обычно принимает форму помещения на Web-страницах собственной информации и обеспечения доступа сотрудников к информации других пользователей, использования электронной почты. В качестве такого сервера может использоваться практически любая вычислительная система. Однако когда компании по-настоящему переходят на электронную форму ведения бизнеса, когда они начинают использовать WWW для важнейших деловых операций, требования к надежности и целостности системы многократно возрастают.

Многие годы AS/400 — производительная, работоспособная, надежно защищенная система для традиционных и клиент-серверных приложений. Теперь мы даем своим заказчикам возможность применить эти ее замечательные свойства в мире электронного бизнеса.

 

Как читать эту книгу

Допускаю, что сам факт подобных рекомендаций может показаться читателю странным, но на то есть веские причины. Предполагаемая аудитория достаточно широка: от деловых людей, желающих понять, чем система или сервер AS/400е могут быть выгодны их бизнесу, до «спецов», которые хотят разобраться в мельчайших деталях. Я долго ломал голову, как «потрафить» и тем, и другим, намеревался даже разбить книгу на две части: обзор для обычных читателей и технические детали для «профи». Но как быть с теми, кому интересно все? Думал я и о том, чтобы снабдить книгу указателем, по которому и менеджер, и разработчик приложений, и студент, и любитель подробностей могли бы найти разделы, предназначенные специально для них. Но такая классификация слишком условна; всякий раз, когда я читаю какую-нибудь книгу в соответствии с подобным «путеводителем», мне самому трудно ориентироваться, какие разделы читать, а какие — пропустить.

Не знаю, чем закончились бы мои мучения, если бы не Малколм Хейнес (Malcolm Haines) из Лондона — одна из самых светлых голов в IBM. Малколма часто называют «министром пропаганды:» IBM UK, в его обязанности входит реклама IBM через видео-и коммерческие спутниковые телесети. Его компакт-диск «The Case Against the AS/ 400» — гениальный образчик британского юмора.

Именно Малколм посоветовал пометить наиболее трудные разделы — а там уж пусть читатель сам решит, читать их или нет. Еще он предложил использовать для обозначения степени сложности раздела перчик чили. Почему, это особая история. В прошлом году Малколм повел меня в англо-индийский ресторан Chutney Mary в Лондоне. Так вот, в меню этого уютного заведения картинки красного перчика чили обозначали остроту блюд — чем больше перчиков, тем острее. И Малколма осенило: почему бы не обозначить так же «остроту» технических разделов книги?!

Вот как выглядит в результате мой «гастрономический» рейтинг:

Отсутствие перчиков означает, что, с точки зрения технических подробностей, раздел довольно «пресный». Кое-что, конечно, есть, но любому читателю стоит добавить чуточку специй.

Один перчик — «техники» побольше. Это уровень, так сказать, массового читателя. Попробуйте, — а вдруг Вам придется по вкусу?

Два перца означают, что здесь определенно рассматриваются технические проблемы. И если для Вас это слишком, листайте до менее «острого» раздела.

Три чили — ау, любители острых блюд и ощущений! «Спецы» хищно улыбаются, утирая со лба пот. Не исключено, что при слишком внимательном чтении кто-нибудь почувствует запах жареного. Что тут посоветовать? На всякий случай держите под рукой стакан с водой или совсем пропустите подобный раздел.

Приятного аппетита!

 

Глава 1

 

Расширенная архитектура приложений

Выносливость любой компьютерной системы и ее способность сохранять инвестиции, — самые важные аргументы при выборе компьютера для производства или офиса. Ураган новых технологий, таких как Интернет, захлестнул деловой мир, заставил многих предпринимателей в корне изменить методы своей работы. Сегодня одна новейшая технология меняет другую с поразительной быстротой, постоянны только изменения. Насущным стало не только с выгодой использовать эти изменения для укрепления бизнеса, но и защититься от потерь, вызванных ими.

Общеизвестно, что у AS/400 прогрессивная, самая адаптируемая архитектура в мире, и что новые технологии не повлияют негативно на бизнес заказчиков этой системы. Да, это правда. Пользователям AS/400 не требуется «подгонять» свои прикладные программы под новые технологии. Однако, зачастую сами клиенты не понимают (или не хотят понимать) как работает система. Работает — и ладно!

Недавно архитектура AS/400 снова оказалась в центре внимания. AS/400 стала первой и единственной в мире системой, завершившей переход к 64-разрядным вычислениям. В новой модели был использован тип архитектуры процессора с сокращенным набором команд — RISC (reduced instruction set computer). Для сравнения: процессоры, использовавшиеся в исходной AS/400, а также другие популярные процессоры, такие как Intel Pentium или Intel Pentium Pro, используют архитектуру со сложным набором команд — CISC (complex instruction set computer). Главное достоинство RISC-архитектуры — более простые команды, чем у CISC. Это позволяет создавать процессоры, отличающиеся поразительной быстротой вычислений и за приемлемую цену. Последние версии RISC-процессоров всех производителей — 64-разрядные.

Проектирование и создание такой аппаратуры — не самая сложная проблема компьютерной индустрии. А вот как предоставить существующему программному обеспечению (ПО) возможность воспользоваться преимуществами новой аппаратуры? AS/400 — единственная система, где эта проблема решена. Все ее приложения используют 64-разрядные вычисления в полной мере.

Никакая другая система такими возможностями не обладает. Когда другие производители компьютеров переходили с CISC- на RISC-процессоры, это вызывало серьезные проблемы у их заказчиков и независимых производителей програмно-го обеспечения ISV (Independent Software Vendor), которым приходилось переписывать некоторые прикладные программы или их фрагменты. Так случилось, например, когда фирма Hewlett Packard объявила о своей архитектуре PA (Precision Architecture), или когда Digital Equipment Corporation (Digital) представила архитектуру Alpha.

Чтобы лучше понять масштаб проблемы, остановимся подробнее на попытке перехода на RISC, предпринятой фирмой Digital. По собственной оценке Digital перевод имеющегося парка на архитектуру Alpha вызовет необходимость переписать от 15 до 20 процентов старого кода приложений, предназначенных для архитектуры VAX. Любому заказчику или ISV такая модификация влетит в копеечку.

Архитектура AS/400, напротив, защищает пользователей системы и ISV от этих проблем при переходе на новые 64-разрядные RISC-процессоры. Существующие приложения сразу же в полной мере используют новые возможности аппаратуры.

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

 

Архитектура компьютера

Витрувий, римский архитектор I столетия нашей эры, определял архитектуру как акт проектирования структуры, обладающей полезностью, прочностью и способностью восхищать. Это и многое другое — общие характеристики как для архитектуры зданий, так и для архитектуры компьютеров.

Современная архитектура многим обязана классической. Корни даже самых футуристических проектов — в прошлом. Египетские пирамиды, греческие колонны, римские арки, романские купола и острые готические своды — все это лежит в основе самых новомодных конструкций. Античная эра истории компьютеров протекала лишь несколько десятилетий назад. Но, как и в проектировании зданий, в самых динамичных и восхитительных примерах современной архитектуры компьютеров четко прослеживается влияние классики.

Модель, лежащая в основе архитектуры AS/400, была разработана более четверти века назад. Благодаря гибкому подходу к проектированию, применявшемуся с самого начала, AS/400 способна быстро адаптироваться к современным условиям и потребностям. Ее архитектура не зависит от технологий, и AS/400 уже многие годы обладает средствами и возможностями, до сих пор недоступными для других вычислительных систем.

 

С точки зрения программиста

В 1970 году С. С. Хассон (S. S. Husson) определил термин «архитектура компьютера» как «характеристики (вычислительной) системы с точки зрения программиста». Архитектура включает в себя набор команд, типы данных, операции ввода-вывода и другие характеристики. Иногда эти компоненты рассматриваются по отдельности, и тогда говорят об архитектуре наборов команд и архитектуре ввода-вывода. Архитектура в целом включает в себя все, что нужно знать программисту для создания корректно работающих программ.

С точки зрения аппаратуры у компьютера имеется пять основных компонентов: ввод, вывод, память, тракт данных (datapath) и устройство управления. Два последних компонента часто объединяют и называют процессором. Архитектура компьютера определяет, какие операции могут выполнять эти компоненты. Процессор выбирает данные и команды из памяти. Аппаратура ввода записывает данные в память, а аппаратура вывода — считывает из нее. Управляющая аппаратура генерирует сигналы, управляющие трактом данных, памятью, вводом и выводом.

Иногда процессор называют ЦПУ — центральным процессорным устройством CPU (central processing unit). В последнее время этот термин используется реже, так как современные технологии позволяют упаковать целый процессор в одну микросхему. Процессор, выполненный на одной микросхеме, обычно называют микропроцессором. Достаточно часто термины «ЦПУ», «процессор» и «микропроцессор» используют как эквивалентные. Однако, следует помнить, что не всякий процессор умещается на одной микросхеме — их может потребоваться несколько.

Если два компьютера могут выполнять один и тот же набор команд, то говорят, что у них одинаковая архитектура набора команд. Одна и та же архитектура может быть реализована по-разному. Так, например, архитектура Intel x86, применяемая во многих ПК, используется целым семейством микропроцессоров, созданных с помощью разных технологий и имеющих разную производительность. То есть конкретная технология, использованная при создании компьютера, не есть часть его архитектуры.

 

Уровни абстракции

Аппаратные и программные структуры большинства современных компьютеров — многоуровневые. Детали нижних уровней скрываются, чтобы обеспечить более простые модели для верхнего уровня. Данный принцип абстракции — способ, благодаря которому проектировщики аппаратных и программных средств справляются со сложностью вычислительных систем.

На самом нижнем уровне — электронных схем — компьютер очень прост. Электронная схема понимает только две команды: включено и выключено, символически обозначаемые при помощи цифр 1 и 0. На данном уровне общение с машиной идет с помощью цепочек нулей и единиц. Команда — это понятный процессору набор двоичных цифр или битов (разрядов). Таким образом, команда представляет собой просто число в двоичной системе счисления или двоичное число. Компьютеры называются цифровыми, потому что на машинном языке для обозначения как команд, так и данных используются цифры.

Когда-то давно, программисты «общались» с компьютерами на языке двоичных чисел. Это не слишком удобно, поэтому был изобретен более высокий уровень абстракции — язык ассемблера, представляющий собой символическую форму двоичного языка компьютера. Ассемблером называется программа, транслирующая символическое представление команд в двоичную форму.

Для большинства программистов язык ассемблера — также не вполне естественный, поэтому был создан еще более высокий уровень абстракции — язык программирования высокого уровня (ЯВУ). В настоящее время насчитываются сотни таких языков; наиболее известные из них — Basic, C, C++, Cobol и RPG. Программа, принимающая на входе текст на одном из языков высокого уровня и транслирующая его в операторы языка ассемблера, называется компилятором.

Иллюстрация многоуровневой абстракции — написание программы на языке высокого уровня. Компилятор выполняет преобразование программы на ЯВУ в язык ассемблера, который затем переводит свои команды в двоичный код, понятный процессору. Замечу, что некоторые компиляторы генерируют команды непосредственно на машинном языке, минуя уровень ассемблера.

Перед выполнением программы на ЯВУ компилятор и ассемблер транслируют ее в команды машинного языка. Эта операция выполняется однократно, и при новом запуске программы повторять ее не надо, если только исходный текст программы не изменился. Наличие нескольких уровней позволяет скрыть детали нижележащего машинного языка от программиста и обеспечить более простой и производительный интерфейс.

Многоуровневая концепция может также использоваться и в аппаратуре компьютера. Многие процессоры, в том числе из семейства Intel, используют микропрограммирование. В микропрограммируемой машине применяется набор команд еще более низкого уровня. Для отображения между верхним и нижним уровнями микропрограммирование использует эмуляцию. При этом машинные команды выбираются и исполняются по одной, как последовательность команд более низкого уровня. Для преобразования машинных команд в форму, приемлемую для микропрограммы, не требуется отдельный этап компиляции.

Похожа на эмуляцию интерпретация программ. Программа-интерпретатор выбирает инструкции по одной и исполняет эквивалентную им последовательность команд более низкого уровня. Некоторые из новейших ЯВУ, используемых в распределенных вычислениях, например Java, разработаны так, чтобы их было легко интерпретировать. Большинство командных языков также интерпретируемы. Введите «dir» в командной строке DOS на любом ПК и на экране появится содержимое каталога. Если после этого нажать клавишу Enter, интерпретатор командной строки DOS считает введенную команду, а затем выполнит последовательность инструкций, необходимых для ее выполнения. Такой интерпретатор команд есть в большинстве операционных систем. В микропрограммируемой машине интерпретация обычно поддерживается специальным оборудованием. Микропрограмма для различения такой аппаратной формы интерпретации называется эмулятором.

Обычно архитектура набора команд вычислительной системы рассматривается как интерфейс между аппаратурой и программным обеспечением самого нижнего уровня. В те времена, когда Хассон сформулировал упоминавшееся выше определение архитектуры компьютера, программирование еще не использовало ЯВУ. Сегодня, более подходящим определением этого понятия было бы «характеристики системы с точки зрения компилятора», так как из нынешних программистов лишь немногие имеют дело с программами в машинных кодах.

С учетом многих уровней абстракции, более точно было бы говорить, что компьютер имеет несколько архитектур, хотя архитектура двоичного набора команд в большинстве случаев по-прежнему играет основную роль. Когда говорят, что один компьютер способен выполнять программы, написанные для другого компьютера без изменений, то обычно имеют в виду, что первый может выполнять двоичные коды (binaries) другого, и следовательно, для переноса программ с первого на второй их повторная компиляция не требуется. Иначе говоря, двоичный машинный язык одного компьютера непосредственно поддерживается другим компьютером.

 

Создание программ

Программное обеспечение любой вычислительной системы можно условно разделить на два типа: системное и прикладное. Примеры системного программного обеспечения — операционные системы, ассемблеры и компиляторы. Прикладное же программное обеспечение обычно предназначается непосредственно для пользователей и решает конкретные задачи.

Ранее считалось, что доступ к архитектуре самого нижнего уровня посредством ассемблера необходим как системному, так и прикладному программисту. В пользу этого суждения приводилось множество аргументов: большинство программ имели доступ к крайне незначительному объему памяти, процессоры были медленными и дорогими, а компиляторы с языков высокого уровня — не слишком хорошими. Когда нужно было «выжать последний грамм» для повышения производительности компьютера, «настоящие» программисты использовали язык ассемблера.

Теперь же появилось много приверженцев мнения, что программирование на языке ассемблера — реликт прошлого. Но это не так. Большинство используемых ныне операционных систем (не только старых, чьи корни которых восходят к 60-м и началу 70-х годов, но и более современных) включают в себя большие объемы кода на ассемблере. Таковы, например, операционные системы для ПК: Windows 95 фирмы Microsoft написана по большей части на языке ассемблера Intel.

Первые процессоры для ПК имели достаточно ограниченные возможности. Максимальный размер памяти был равен 64 килобайтам. (Один килобайт равен 210 или 1024 байтам. Байт — это 8-разрядная ячейка памяти, в которой может храниться символ или цифра). Память стоила настолько дорого, что операционные системы могли занимать не более 4 килобайт. Язык ассемблера позволял программистам максимально сокращать размер кода. В результате на нем написан такой большой объем операционных систем, что даже когда размер доступной памяти увеличился благодаря удешевлению технологии, возвращаться назад и переписывать оригинальный код оказалось непрактичным.

Использование ассемблера действительно позволяет оптимизировать размеры и производительность программ. Тем не менее, у этой технологии, по крайней мере, один существенный недостаток: все программы напрямую привязаны к аппаратуре. Любое ее изменение может вызвать необходимость переписать некоторые или даже все программы.

В качестве примера такой ситуации рассмотрим компьютер, имеющий восемь регистров. Регистр — часть тракта данных процессора. Это быстродействующая область памяти, куда помещаются данные и адреса на время их использования процессором. Основное назначение регистров — повышение производительности работы программ. Предположим, что ширина каждого регистра — 16 разрядов, и что программист может помещать данные в регистры и выбирать их оттуда в любой момент по своему усмотрению. Число регистров и их характеристики программист видит из ассемблера. Таким образом, каждая программа для данного компьютера, написанная на этом языке, будет «знать» о восьми регистрах и зависеть от них.

Теперь предположим, что технологический прогресс позволил конструкторам увеличить количество регистров до 16 и сделать их 32-разрядными, причем стоит все это столько же, сколько и оригинальные 8 регистров меньшего размера. Зададимся вопросом: «Как это повлияет на программы, написанные для старого компьютера?». Ответ зависит от того, каким образом были сделаны изменения, и сколь хорошо первоначальная архитектура была спланирована для расширения в будущем.

Допустим, что в старой архитектуре предполагалось расширение до 16 регистров. В каждой команде было зарезервировано достаточно места для адресации 16 регистров, хотя первоначально были реализованы только 8. Для каждой команды, использующей регистры, в данном случае понадобились бы 4-разрядные поля, так как 4 бита позволяют закодировать 16 различных комбинаций нулей и единиц. На новом оборудовании старые программы могут выполняться без изменений. При этом они по-прежнему будут использовать только 8 регистров, новые же программы смогут воспользоваться всеми 16-ю.

А теперь представим себе вместо этого, что в старой архитектуре не были учтены будущие изменения и место для расширения не зарезервировано. Тогда новая архитектура не сможет увеличить количество регистров, не изменив при этом каждую команду, которая их использует. Невозможно растянуть трехбитовые поля в командах до 4 бит, не затронув при этом в той или иной степени существующие программы.

Одна из многих архитектур, неспособных увеличить число пользовательских регистров, — Intel Pentium Pro. Она использует то же количество регистров, что и ее предшественник Intel 386. Хотя увеличение числа регистров дало бы Pentium Pro преимущества, но затраты на переписывание существующих ассемблерных программ слишком велики.

Вообще, увеличение размера регистров с 16 до 32 разрядов оказывает меньшее влияние, чем изменение их количества. Если увеличился только размер, то старые программы будут по-прежнему работать, но использовать лишь 16 из 32 разрядов новых регистров. Данная информация внедрена в логику программы, и ее трудно изменить.

И подобных примеров, когда широко применяемые программы не способны использовать все ресурсы оборудования, — несметное множество. Процессор Intel 386, появившийся еще в 1985 году, имел 32-разрядный дизайн, то есть размер его аппаратных регистров был равен 32 битам. С того времени все процессоры Intel, включая 486, Pentium, Pentium II и Pentium Pro — 32-разрядные. Однако и большинство программ для ПК, использующих эти процессоры, и операционная система DOS были созданы в те времена, когда был доступен только 16-разрядный процессор Intel 286. Даже операционная система Windows 95 написана в основном на 16-разрядном ассемблере. На переписывание прикладных и системных программ ПК под 32-разрядную аппаратуру ушло уже 12 лет, и процесс все еще не завершен.

Эта проблема не ограничивается только индустрией ПК. Прогресс аппаратных технологий поднял планку еще выше: большинство новых процессоров будут 64-разрядными. Чтобы воспользоваться этим более мощным оборудованием, большинство современных 32-разрядных операционных систем и 32-разрядных прикладных программ должны быть переписаны. А это опять долгие годы работы.

В рассмотренных выше примерах модификации аппаратуры состояли в изменении размера и числа регистров процессора. Учтите, что аналогичное влияние на программное обеспечение, написанное на ассемблере, могут оказать и изменения в структуре адресации процессора или в самом наборе команд.

Основная цель программирования только на языках высокого уровня — минимизировать изменения в программах, вызываемые подобными модификациями аппаратуры. К сожалению, в системном программном обеспечении явно наблюдается тенденция перехода на языки, подобные С и С++. Использование С позволяет повысить переносимость системного программного обеспечения, так как компиляторы для этого языка есть на многих аппаратных платформах, но не устраняет все сложности, связанные с изменениями в оборудовании. Некоторые аппаратные характеристики, например разрядность процессора, видимы программисту на С. Такая возможность доступа к внутренним характеристикам привлекательна для системных программистов и объясняет популярность С. Это язык называют «современным ассемблером». В обычной вычислительной системе переход, например, с 32-разрядного процессора на 64-разрядный по-прежнему будет требовать изменений в программе на С. А это снижает переносимость С-программ.

Для иллюстрации рассмотрим опыт Digital. Последние несколько лет эта фирма продает свои машины с 64-разрядным процессором Alpha. Однако две основные операционные системы, используемые на этих компьютерах — Open VMS самой Digital и Windows NT фирмы Microsoft — все еще 32-разрядные, хотя и написаны, в основном, на С. Приложения для этих операционных систем, также 32-разрядные. Простая перекомпиляция здесь не поможет. Чтобы задействовать все ресурсы процессора, и операционные системы, и приложения надо полностью переписать, и это займет много лет.

HP также загнала покупателей своей HP 9000 в трясину переделок. Сейчас HP продает 64-разрядные версии своих процессоров PA-RISC. Чтобы воспользоваться преимуществами новых аппаратных средств, заказчикам HP придется ждать появления новой 64-разрядной ОС, и затем переписывать свои приложения. На это потребуется столько времени, что уже теперь, задолго до того, как переделка ПО будет завершена (см. главу 12), есть признаки того, что HP может отказаться от дальнейшей разработки HP 9000.

Секрет успешного перехода к 64-разрядным вычислениям на AS/400, в то время как никому больше это не удалось, кроется в ее архитектуре.

 

Классификация архитектур

Принципов классификации компьютерных архитектур немало. Вероятно, самый старый из них — по формату команд процессора. Другой, уже знакомый, — разделение процессоров на категории CISC и RISC. Оба эти подхода учитывают только аппаратный интерфейс процессора. С точки же зрения заказчика прикладные программы гораздо важнее. Следовательно, не менее законно будет классифицировать компьютерные архитектуры по способу взаимодействия прикладных программ с аппаратным интерфейсом.

 

Процессоро-ориентированная архитектура

Подавляющее большинство используемых ныне компьютерных архитектур основаны на традиционном подходе, открывающем программисту аппаратный интерфейс. Такие архитектуры называются процессоро-ориентированными (processor-centric) потому, что аппаратный интерфейс в них видим прикладным программам и используется последними непосредственно. Примеры процессоро-ориентированных архитектур — PA фирмы HP и Alpha фирмы Digital.

 

API-ориентированные архитектуры

Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API (application programming interface). Такие API-ориентированные архитектурыустанавливают коммуникационный барьер — интерфейс, который используется всем прикладными программами для доступа к сервисам операционной системы и изолирует их от аппаратных и программных деталей.

Операционная система — это набор программ, управляющих системными ресурсами и служащих фундаментом для написания прикладных программ. Часто таким фундаментом становятся API. Существуют различные формы реализации API. Это может быть вызов или команда, запрашивающая у операционной системы согласие на выполнение некоторых действий. Хорошо известный пример API — функция операционной системы, вызываемая прикладной программой для выполнения операции ввода-вывода, такой как чтение с диска. Очевидно, что прикладной программе незачем «знать» подробности внутренней работы ввода-вывода. Программы операционной системы, выполняющие функции ввода-вывода и часто называемые подсистемами ввода-вывода, изолируют приложения от деталей аппаратной и программной реализации. Приложения, использующие для выполнения ввода-вывода только соответствующие API, не зависят от каких-либо изменений в структуре ввода-вывода на нижних уровнях.

Дополнительное преимущество дает реализация разными производителями одного и того же набора API. В этом случае приложения легко переносить с одной системы на другую. Один из наиболее известных стандартных наборов API — POSIX. POSIX — сокращение, неформально расшифровываемое как «переносимый интерфейс операционной системы базирующейся на Unix» (portable operating system interface based on Unix) — это набор международных стандартов для интерфейсов Unix-подоб-ных операционных систем. Правительственные и неправительственные организации поощряют реализацию производителями Unix-подобных операционных систем данных стандартов, как обеспечивающую переносимость приложений с одной системы на другую.

Общая проблема стандартов типа POSIX состоит в том, что они никогда не становятся законченными, и стадия определения такого стандарта занимает многие годы. В такой ситуации разработчики приложений часто берут дело в свои руки. В 1993 году группа разработчиков приложений для Unix и производителей Unix-подобных операционных систем решила определить свой собственный набор API. Они не могли ждать, пока спецификация POSIX «созреет» до такой степени, чтобы ее можно было использовать. Кроме того, ясно, что когда спецификация POSIX будет, наконец, полностью завершена, все приложения придется переписывать под новый стандарт.

Вместо этого, упомянутая группа разработчиков выделила все API, которые используются в настоящее время наиболее популярными приложениями для Unix. Из тысяч существующих Unix-приложений они взяли 50 самых распространенных и выбрали 1179 функций API в качестве основы нового стандарта, который первоначально был назван SPEC1170. Позднее это название было заменено на «Единая Спецификация UNIX» (Single UNIX Specification), и данный стандарт становится теперь новой промышленной спецификацией Unix. Помимо указанных API в него входит часть интерфейсов POSIX. В состав спецификации продолжают включаться новые API.

Очевидная проблема во всей этой работе по определению API была лаконично сформулирована одним из сотрудников института NIST (National Institute of Standards and Technology Национального института стандартов и технологий США): «Самое милое в стандартах — это большой их выбор». В самом деле, множество противоречащих друг другу и быстро изменяющихся стандартов делает невозможным создание приложения, которое было бы переносимо на все платформы. Далее, в главе 11, мы рассмотрим язык программирования Java и предоставляемые им возможности по созданию переносимых приложений.

Более того, эти стандарты не являются полными, то есть во многих случаях приложениям приходится действовать «в обход» API. В результате приложение становится зависимым от аппаратуры и программного обеспечения нижних уровней: в тот момент, когда приложение обходит API, все проблемы, присущие процессоро-ори-ентированным архитектурам, возникают снова.

 

Машинная архитектура высокого уровня

Истинная независимость от аппаратуры может быть достигнута, если вместо определения отдельных API для разных специфических приложений (что имеет место в случае такой API-ориентированной архитектуры как Single Unix Specification), будет формально определен общий интерфейс для всех приложений. Более того, если в такой интерфейс заложены возможности расширения, то в любое время для достижения переносимости приложений к нему могут быть добавлены API Single UNIX Specification. Именно такой подход лежит в основе архитектуры AS/400, которая определяет законченный набор API для всех приложений и не позволяет последним обходить API.

Независимый от технологии машинный интерфейс (Technology-Independent Machine Interface), который часто называют просто MI, представляет собой формальное определение интерфейса для всех приложений и большинства компонентов операционной системы. Аппаратура, а также все программное обеспечение операционной системы, которому должны быть доступны подробности аппаратной реализации, располагаются ниже границы MI.

Чтобы понять, как достигается независимость программного обеспечения от изменений в аппаратуре, обусловленных технологическим прогрессом, необходимо кратко рассмотреть, как работает компилятор. Ранее было сказано, что в традиционной процессоро-ориентированной системе компилятор генерирует двоичный машинный код непосредственно из исходного текста, что иногда требует дополнительного шага ассемблирования. В AS/400 компилятор генерирует из исходного текста код MI, который оформляется в виде так называемого шаблона программы. На втором этапе транслятор AS/400 генерирует двоичный код по содержимому шаблона программы. Фактически, этот транслятор выполняет те же действия, что и заключительный проход современного компилятора. Затем, если явно не запрошено его удаление, шаблон программы сохраняется вместе с двоичным кодом в программном объекте. Такая программа называется отслеживаемой (observable). При переносе программного объекта на новую аппаратную базу, например, на 64-разрядный PowerPC, другой транслятор, созданный для новой аппаратуры, перетранслирует шаблон программы в новый двоичный код. Изменений в исходном коде при этом не требуется — чем и достигается независимость от технологии. Более подробное рассмотрение этого вопроса мы отложим до главы 4.

Значимость такой независимости очевидна для пользователей и ISV. Переход на 64-разрядную технологию RISC дает не только более мощный процессор — операционная система и все приложения сразу же становятся 64-разрядными. Для того чтобы воспользоваться преимуществами 64-разрядного оборудования не нужно ничего переписывать. В один день RISC-системы AS/400 получают 64-разрядную операционную систему и десятки тысяч 64-разрядных приложений.

Архитектура AS/400 заслужила титул «расширенной архитектуры приложений» (Advanced Application Architecture), так как предоставляет возможности, которых многие другие вычислительные системы все еще пытаются достичь с помощью API-ориентированного подхода. AS/400 уже сейчас независима от нижележащей технологии. Хотя независимость от аппаратуры важна, но не менее важна и независимость от деталей операционной системы. В AS/400 достигнуто и это. Термин «расширенная архитектура» подразумевает, что к ней могут быть добавлены вновь определяемые API других операционных систем, что обеспечивает еще большую переносимость приложений.

 

И это тоже есть!

«Это там есть; все там есть!», — восклицает телевизионная реклама известного соуса для спагетти. Вместо того, чтобы покупать ингредиенты и делать соус самому — убеждает голос за кадром — лучше просто купить бутылку этого соуса и быть уверенным, что все качественные и свежие составляющие, которые Вы использовали бы, уже там. Гленн Ван Беншотен (Glenn Van Benschoten), системный менеджер AS/400, любит использовать аналогию с соусом для спагетти для описания интегрированной сущности AS/400. Все, что Вы можете пожелать для своего компьютера, уже там есть.

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

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

Если задать тот же вопрос ISV, то он, вероятно, скажет, что для AS/400 проще, чем для какой-либо другой платформы, разрабатывать и сопровождать приложения. ISV, имеющие свои приложения как для AS/400, так и для других платформ, например Unix, часто указывают на разницу в численности людей, работающих для одной или другой платформы. Обычно, для разработки приложений для AS/400 требуется гораздо меньше людей, и это также — заслуга интеграции. Гарантируя, что новая добавленная функция будет гладко работать со всеми остальными частями системы, мы сокращаем расходы на разработку для AS/400. Все системы, созданные в Рочес-тере до AS/400 включительно, решены интегрировано, и именно в этом секрет их успеха.

Но если даже наши собственные разработчики порой забывают об этом факторе, то благодаря чему AS/400 остается интегрированной системой? Ответ — MI. MI делает для обеспечения интеграции две вещи. Во-первых, он предоставляет общий интерфейс для всех приложений и функций операционной системы, реализованных поверх него, благодаря чему всем приходится использовать систему одинаковым образом. Во-вторых, MI — функционально законченный интерфейс. Так как обойти его невозможно, MI предоставляет все функции, которые могут потребоваться прикладной или системной программе. Если какая-либо нужная функция отсутствует, то программа не будет работать на AS/400. MI также обладает большими возможностями расширения, что позволяет включать в него новые функции по мере надобности.

Прежде чем кто-нибудь укажет на то, что другие системы Рочестера, такие как System/36, добивались интеграции без машинного интерфейса высокого уровня, я должен отметить, что MI обеспечивает и интеграцию, и аппаратную независимость. У System/36 был эквивалент машинного интерфейса для большинства системных функций, но не для приложений. В этой системе два отдельных процессора выполняли: один — пользовательские приложения, а другой — некоторые функции операционной системы. Доступ к этим функциям на втором процессоре был возможен только посредством строго определенного интерфейса между двумя процессорам. Данный интерфейс, подобно MI, гарантировал полноту набора функций и возможность их совместной работы. Приложения, однако, по-прежнему зависели от аппаратуры. По этой причине (как мы увидим в главе 3) для выполнения приложений System/36 на другой аппаратуре требовался эмулятор.

Отрицательная сторона интеграции — отсутствие гибкости. В интегрированных решениях обычно имеет место подход «все или ничего». Клиент не может выбрать

ОС одного производителя, базу данных — другого и пакет защиты — третьего, так как все они не предназначены для работы в интегрированной системе.

Трудно поверить в то, что в любой компьютерной системе есть компоненты, не предназначенные для тесной совместной работы, но часто именно так и обстоит дело. Такие компоненты как базы данных, подсистемы защиты и коммуникаций обычно разрабатываются независимо друг от друга и могут предназначаться для работы с разными ОС. В результате, такие компоненты обычно самодостаточны, то есть стремятся использовать минимальный набор возможностей, встроенных в ОС. Подобное разделение ведет к дублированию функций между ОС и отдельными компонентами. Оно также может привести к разным интерфейсам пользователя и системного оператора.

Преимущество набора из отдельных компонентов состоит в гибкости. Недостаток — в том, что заказчик должен самостоятельно интегрировать такие компоненты в своей вычислительной системе, а это связано с расходами, и не только на собственно интеграцию. Средства тратятся на обучение пользователей и операторов работе с разными интерфейсами, а также на сопровождение. Модернизации одного компонента могут оказать негативное влияние на другой. Все еще более усложняется при использовании компьютеров в сети, которая сама по себе требует сопровождения. В попытке устранить множество несовместимостей между компонентами некоторые предприятия решают закупать все ПО у одного производителя. Но и это обычно не решает проблему.

В общем, ситуация напоминает мне ту, в которой я оказался не так давно при покупке и установке новой аудиовидеосистемы. Каждый из четырех ее компонентов имел собственный пульт дистанционного управления. Поскольку все компоненты произведены одной фирмой, продавец заверил меня, что каждый пульт универсален, то есть может управлять всеми частями комплекса, а следовательно для системы в целом нужен всего один пульт. В действительности оказалось, что с помощью одного пульта можно управлять лишь некоторыми функциями каждого компонента, но не всей системой в целом: для этого надо использовать все четыре пульта. Кроме того, «пользовательские интерфейсы» пультов разные, кнопки для выполнения одной и той же функции находятся на них в разных местах и часто имеют разную форму и размер. Даже названия некоторых идентичных функций различаются. Точно также многим пользователям компьютеров приходится использовать несколько «пультов управления» при эксплуатации своих вычислительных систем. И им, и мне больше подошла бы интегрированная система.

 

Глава 2

 

Технология PowerPC

«По сути своей, IBM s компания технологий», — сказал Лу Герстнер (Lou Gerstner) вскоре после того, как возглавил корпорацию в 1993 году. И действительно, чуть ли не все основные технологии компьютерной индустрии s от RISC до реляционных баз данных s вышли из IBM. В прошлом IBM не всегда удавалось коммерчески использовать свои изобретения, и Герстнер собирается это изменить. По его мнению, главное s продвижение нескольких ключевых технологий, одна из которых — RISC-микропроцессор PowerPC в AS/400 Advanced Series.

 

Микросхемы сжимаются на глазах

Статистика говорит, что сегодня в мире от 300 до 400 миллиардов микросхем, в том числе около 15 миллиардов кристаллов микропроцессоров. В основном, это микросхемы памяти. Произвести их в таком количестве за последние несколько лет позволил быстрый прогресс в технологии кремниевых микросхем. Подавляющее большинство микропроцессоров используются не в компьютерах, а в наручных часах, телевизорах, кухонных приборах и автомобилях. Например, в новом автомобиле обычно от 10 до 12 микропроцессоров, а в некоторых моделях sзначительно больше.

С каждым новым поколением микросхем производителям удается разместить на одном кристалле все больше транзисторов, примерно удваивая это число каждые 18 месяцев. Данная закономерность известна как закон Мура, названный так в честь Гордона Мура (Gordon Moore), председателя и одного из основателей Intel. В 1971 году Intel выпустила свой первый микропроцессор 4004, содержавший 2300 транзисторов на одной микросхеме. Современный кристалл микропроцессора содержит миллионы транзисторов. Предсказание Мура сбывается уже более четверти столетия1. Постоянное сокращение размера транзисторов позволяет увеличивать плотность их упаковки на кристалле. По мнению многих экспертов, вскоре после 2000 года появятся транзисторы размером всего лишь около 0,18 микрона; а еще менее чем через десять лет s 0,08 микрон. Для сравнения, толщина человеческого волоса примерно 80 микрон. Представьте себе тысячу транзисторов, размещенных на его срезе! Судя по такой стремительности прогресса, закон Мура продержится еще не один десяток лет. Не пройдет и десятилетия, и мы, вероятно, увидим микросхемы с более чем 100 миллионами транзисторов; а размещение на одной микросхеме миллиарда транзисторов может стать возможным уже лет через 15 лет. Все это обеспечит та же самая кремниевая технология, которая применяется для современных микросхем. Необходимость ее замены возникнет, по-видимому, не раньше чем через 20 лет. Однако у микросхем с высокой плотностью упаковки есть и минусы. Они невероятно сложны, и их разработка и производство становятся все дороже. В будущем экономические проблемы, вероятно, приведут к прекращению производства микросхем несколькими известными сегодня фирмами. Уже сейчас завод, производящий кристаллы для современных микросхем стоит более 2 миллиардов долларов, а стоимость производства микросхем с размером транзисторов менее 0,1 микрон, вероятно, «перевалит» за 10 миллиардов. С учетом продолжающегося падения цен на полупроводниковые микросхемы, можно предположить, что через 10 лет производителей микросхем останется не более десятка.

Никто не знает, кто выдержит эту гонку, и сегодняшние удачи ничего не гарантируют в будущем. Возьмем, например, Intel. Многие считают, что благодаря популярности ПК, Intel s крупнейший производитель микропроцессоров. Но это не так! Intel производит только около 1,5 процента всех микропроцессоров. Motorola, Hitachi и даже Zilog (помнит ли кто-нибудь Z80?) продают гораздо больше микропроцессоров, чем Intel. Своим успехом Intel обязан, главным образом, высоким ценам, которые он устанавливает на свои микросхемы для ПК. Другие производители продают микросхемы равной производительности дешевле. Но пока существуют ПК, Intel может запрашивать высокие цены.

IBM твердо намерена оказаться в числе тех производителей микросхем, которые выживут в следующем десятилетии. Свои надежды мы возлагаем на процессоры PowerPC, чья технология будет фундаментом AS/400 и другой продукции IBM в течение следующих нескольких лет.

Итак, давайте более подробно рассмотрим эволюцию архитектуры PowerPC и использование ее в AS/400, а затем поговорим о процессорах, используемых в различных RISC-моделях AS/400.

 

Альянс PowerPC

В начале 1991 года Apple Computer подыскивала новый процессор для своих компьютеров. Ее специалисты полагали, что будущее процессоров ПК — в RISC-архитектуре. В то время процессоры ПК, производимые Motorola, Intel и другими фирмами, имели архитектуру CISC. Apple тогда использовала процессоры Motorola, и хотя последняя уже создала RISC-процессор, он не имел большого коммерческого успеха.

У технологии RISC фундаментальные преимущества над CISC. RISC-процессор более производителен, он упакован на кристалле меньшего размера и потребляет меньшую мощность. В Apple поняли, что вычислительная техника, в конце концов, будет двигаться в этом направлении, но в 1991 году подавляющее большинство доступных микропроцессоров по-прежнему имели архитектуру CISC.

В то время IBM производила одни из лучших RISC-процессоров. Они применялись в компьютерах RISC System/6000 (RS/6000). Все эти процессоры имели многокристальную 32-разрядную архитектуру, но IBM планировала выпустить в начале 1992 года однокристальную версию RCS (RISC Single Chip). Узнав, что Apple ищет новый RISC-микропроцессор, в IBM решили узнать, не подойдет ли им продукция IBM.

Оправившись от шока, вызванного тем, что их прямой конкурент на рынке ПК — IBM — пытается продать им процессоры, в Apple решили, что в этом что-то есть. Зная, что Motorola также работает над новым RISC-процессором, Apple предложила объединить усилия трех фирм. После переговоров IBM согласилась, и в сентябре 1991 года три фирмы официально объявили о совместной разработке некоторых новых технологий, включая большое семейство микропроцессоров. В основе дизайна микропроцессоров должен был лежать RSC. Новое семейство получило название PowerPC.

Три партнера понимали, что успех на рынке зависит от объема продаж новых микросхем и возможностей выбора программного обеспечения. Для этого они стали привлекать к использованию PowerPC производителей аппаратного и программного обеспечения, включая Toshiba, Canon, Zenith Data Systems, Harris Computer и Groupe Bull. Чтобы еще больше повысить объем продаж процессоров, члены альянса привлекли и фирмы, работающие вне области вычислительной техники. Хороший пример такого сотрудничества s компания Ford Motor. В будущих автомобилях Ford микропроцессоры PowerPC будут применяться для управления важнейшими узлами — от двигателя до системы торможения.

 

Эволюция PowerPC

Концепция RISC была разработана Джоном Коком (John Cocke) из IBM Research. Кок установил, что прогресс в области компиляторов достиг той точки, когда можно упростить набор команд процессора, и возложить на компилятор значительную часть работы, ранее выполнявшейся аппаратурой. Впервые идеи Кока были воплощены в миникомпьютере IBM 801. Процессоры PowerPC s прямые наследники 801.

Основным мотивом создания архитектур CISC было желание сократить семантический разрыв между двоичным машинным языком процессора и ЯВУ, используемыми программистами. В двоичный машинный язык вводились команды, соответствующие инструкциям языка высокого уровня. Идея заключалась в том, чтобы процессор исполнял меньшее количество сложных команд, что позволило бы сэкономить память. К несчастью, машинные команды стали настолько сложны, что при создании практически любого процессора приходилось применять микропрограммирование. Накладные расходы микропрограммируемого эмулятора замедляли выполнение часто встречающихся простых команд. Кок доказывал, что при использовании только простых команд, необходимость в микропрограммировании отпадет, а все команды будут выполняться аппаратурой непосредственно. Более того, если бы стоимость памяти не была столь существенна, то компиляторы могли бы напрямую подставлять код для выполнения более сложных функций. Потребности в памяти увеличились бы, но возросла бы и производительность.

Дизайн процессора 801 был заимствован у суперкомпьютеров s самых быстродействующих ЭВМ. Хотя сам термин «суперкомпьютер» до середины 70-х годов не использовался, но конструкторы, стремившиеся раздвинуть пределы возможностей аппаратных технологий, были всегда. Невозможно говорить о суперкомпьютерах, не вспомнив о Сеймуре Крее (Seymour Cray). Если хотите, Крей и суперкомпьютер — это синонимы. Современные архитектуры RISC-процессоров многим обязаны этому первопроходцу.

Значительно повысить производительность процессоров позволил метод конвейерной обработки (pipelining). На протяжении уже многих лет эта технология используется при создании всех компьютеров, от ПК до больших ЭВМ. Суть ее — в параллельном исполнении фрагментов последовательных команд на разных этапах аппаратного конвейера. Первый компьютер общего назначения, использовавший конвейерную обработку, появился еще в 1961 году. Это был IBM 7030, известный также под названием Stretch.

Рисунок 2.1а Конвейерный скалярный процессор — пятиэтапный конвейер команд.

Пример пятиэтапного конвейера команд показан на рисунке 2.1а. Время, необходимое для выполнения каждого этапа выполнения команды, называется временем цикла процессора (processor cycle time).

На рисунке 2.1б показана временная диаграмма пятиэтапного конвейера. В течение первого цикла процессора команда № 1 выбирается из буфера команд аппаратурой первого этапа конвейера. В течение второго цикла команда № 1 декодируется, и содержимое необходимых регистров считывается аппаратурой второго этапа. В то же самое время, аппаратура первого этапа считывает из буфера команд команду № 2. Теперь аппаратура разных стадий конвейера параллельно обрабатывает разные части двух разных команд. Благодаря такому параллелизму и достигается повышенная производительность процессоров с конвейерной обработкой. Обратите внимание: предполагается, что некоторая другая часть аппаратуры процессора обеспечивает заполнение буфера команд.

Рисунок 2.1b Пример временной диаграммы

В течение третьего процессорного цикла команда № 1 поступает на стадию выполнения и вычисления эффективного адреса (стадия 3), команда № 2 поступает на стадию 2, а команда № 3 s на стадию 1. Процесс продолжается вплоть до завершения пятого цикла процессора, когда выполнение команды: № 1 заканчивается и она покидает конвейер. Таким образом, выполнение каждой отдельной команды занимает полные пять циклов, но после того, как конвейер заполнен, на каждом цикле процессора завершается выполнение одной команды. Когда говорят, что для выполнения одной команды необходим один цикл процессора, подразумевается, что конвейер заполнен, что, понятно, близко к идеалу.

В начале 60-х годов Сеймур Крей в Control Data Corporation разрабатывал первый в мире суперкомпьютер — CDC 6600. Он планировал использовать конвейерную обработку и добивался, чтобы время выполнения всех команд было одинаковым. Ведь, как видно из приведенного примера, общее время выполнения команд определяется командой, имеющей самое большое время выполнения. Команды, выбирающие операнды из памяти или записывающие их в память, обычно выполняются дольше остальных. Если эти, работающие с памятью, команды выполняют также и логические или арифметические действия над данными, то время выполнения может стать очень большим.

Чтобы максимально сократить общее время выполнения команд, Крей решил, что в его процессоре единственными операциями с памятью будут загрузка в регистр содержимого памяти по некоторому адресу и сохранение содержимого регистра по некоторому адресу в памяти. Любые действия над данными должны производиться только в регистрах.

Тогда это было очень непривычно: ведь большинство других компьютеров позволяли выполнять операции над данными в памяти без использования регистров. Например, команды S/360 позволяют сложить два находящихся в памяти операнда и записать сумму обратно в память. Эта операция занимает очень много времени, но выполняется одной машинной командой. Команды данного типа называются командами память-память.

Для выполнения той же самой операции на машине Крея потребовалось бы пять команд. Сначала две команды загрузки поместили бы данные в два регистра. Затем команда сложения просуммировала бы содержимое этих регистров и поместила бы результат обратно в регистр. И, наконец, команда сохранения переписала бы сумму из регистра в память. Но если эффективно поместить все эти пять команд на конвейер и выполнять их параллельно, то общее необходимое для этого время будет меньше времени, необходимого для выполнения эквивалентной операции на машине с командами типа память-память. И все же большее число команд, требуемых для выполнения операции, было недостатком машины Крея.

В 1964 году появилась CDC 6600 s первая машина общего назначения с архитектурой загрузка/сохранение (load/store). Крей осознал связь между конвейерной обработкой и архитектурой набора команд, и это привело его к выводу о необходимости упрощения этой архитектуры для повышения эффективности конвейера. Современные RISC-процессоры используют подход Сеймура Крея — в них команды, работающие с памятью, выполняют только загрузку и сохранение. Вот почему RISC-машины быстрее CISC-машин с полным набором команд для работы с памятью. По той же причине и программы, скомпилированные для RISC, больше по размеру.

Вклад Сеймура Крея в разработку высокопроизводительных конвейеров не ограничивается только архитектурой набора команд. В CDC 6600 он применил аппаратуру, которая обеспечивала максимум производительности путем максимально возможной загрузки конвейера, то есть ситуацию, при которой на каждой его стадии выполняется часть некоторой команды. В реальности, между командами в программах существуют зависимости. Если команда на конвейере использует данные, которые сохраняются командой, идущей по конвейеру непосредственно впереди нее, то в определенный момент эти данные могут быть еще недоступны, что не только вызывает простой конвейера, но и останавливает выполнение всех последующих команд. Тем самым уменьшается производительность процессора.

В CDC 6600 было впервые реализовано оборудование, позволяющее процессору просматривать команды, расположенные далее в потоке команд, и определять, могут ли они быть запущены перед той, что ожидает сохранения результата. Идея аппаратного переупорядочивания команд на конвейере, известная как динамическое планирование (dynamic scheduling), служила поддержанию максимально возможной его загрузки и значительно повысила производительность CDC 6600.

В суперкомпьютерах 60-х была реализована и идея предсказания переходов. Команда перехода может разрушить конвейер. Вызванный ею простой затянется до тех пор, пока система не будет в состоянии решить, какая команда должна выполняться следующей. Идея предсказания переходов состоит в том, чтобы на основе опыта угадать, откуда следует выбирать команду, следующую после команды перехода. Использованное в IBM 360/91 сложное аппаратное обеспечение предсказания переходов позволило достичь отличных результатов.

360/91 обладала еще одной интересной аппаратной особенностью. Опираясь на ее опыт, Боб Томасуло (Bob Tomasulo), инженер IBM, усовершенствовал алгоритм Крея, созданный несколькими годами ранее, и создал новый алгоритм динамического планирования. Реализованный аппаратно, алгоритм Томасуло устранил многие случаи простоя конвейера путем выполнения команд не по порядку их следования. Команда, которая должна ожидать получения некоторого результата, более не останавливает команды, следующие за ней. Алгоритм Томасуло требовал невероятно сложной по тем временам аппаратуры, но на деле позволял достичь желаемого роста производительности.

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

В конце 60-х годов Джон Кок работал над проектом быстрого компьютера для научных расчетов в IBM Research Laboratory в Сан-Хосе (San Jose), штат Калифорния, и вплотную столкнулся со сложностью оборудования, необходимого для поддержания загрузки конвейера. Кок полагал, что если переложить большую часть ответственности за это на компиляторы, то оборудование значительно упростится и подешевеет. И тогда высокопроизводительная обработка перестанет быть прерогативой суперкомпьютеров. Так родилась идея RISC.

К сожалению, этот исследовательский проект был прерван прежде, чем Кок смог реализовать свои идеи. Еще один шанс сделать это представился ему в 1976 году, в исследовательской лаборатории IBM Yorktown в Нью-Йорке. Коку было поручено спроектировать и построить высокопроизводительный контроллер телекоммуникаций. Именно этот контроллер, получивший кодовое наименование 801 (по номеру здания, в котором работал Кок) обычно считается первым RISC-компьютером.

801 доказал, что планирование загрузки конвейерного процессора может быть возложено на компилятор. Сочетание компилятора, генерировавшего поток команд, оптимизированный для конкретного конвейерного процессора, и упрощенного процессора типа загрузка/сохранение, аналогичного машине Сеймура Крея, до сих пор остается непревзойденным.

Современные RISC-процессоры используют идею Джона Кока s оптимизирующий компилятор, соответствующий аппаратуре процессора. Их производительность обеспечивается технологическими достижениями как аппаратуры, так и компиляторов. Поскольку за последние несколько лет компиляторы очень быстро прогрессируют, то есть даже предложения переименовать RISC в «Relegate Interesting Stuff to Compilers».

Первым продуктом IBM, в котором использовались идеи 801, был PC RT. Подразделению по созданию продукции для офисов в Остине понадобился новый процессор. В качестве отправной точки для разработки был взят 801. Новый микропроцессор, названный ROMP (Research/Office Products Microprocessor), включал в себя подмножество 801, что обеспечивало низкую себестоимость. Главным архитектором и менеджером разработки PC RT выступал Гленн Хенри. Ранее он был программным менеджером нашего проекта в Рочестере, а после выхода на рынок System/38 перебрался в Остин, где возглавил первый проект IBM по созданию RISC-компьютера.

801 использовался также и другими организациями в качестве базы для создания RISC-процессоров. В начале 80-х исследования по этой теме велись группой Дэвида Паттерсона (David Patterson) в Калифорнийском университете в Беркли (Berkeley) и группой Джона Хеннеси (John Hennessy) в Станфордском университете. Именно Паттерсон и придумал термин «RISC». Выпускники обоих упомянутых университетов работали в IBM Research и знали 801. Проект Паттерсона лег в основу микропроцессора SPARC, использовавшегося компанией SUN, а проект Хеннеси s микропроцессора MIPS. Тем временем, в расположенной по соседству компании HP разработкой архитектуры PA-RISC занимался Джоел Бирнбаум (Joel Birnbaum), ранее возглавлявший группу 801 в IBM Research. Таким образом, PA-RISC также s прямой потомок проекта 801.

Ранние процессоры RISC, как и 801, использовали один конвейер. Кок и другие сотрудники IBM полагали, что повысить производительность можно путем распределения на каждом цикле нескольких команд из обычного линейного потока по нескольким конвейерам. Такой компьютер был создан и назван суперскалярным. Первый суперскалярный RISC-процессор появился в 1990 году в RS/6000. В основе его архитектуры также лежал 801.

Чтобы отметить суперскалярное расширение RISC-процессора, IBM назвала эту архитектуру POWER (Performance Optimization With Enhanced RISC). Архитектура POWER стала стартовой площадкой объединенного проекта Apple, IBM и Motorola.

Рисунок 2.2. Эволюция PowerPC

Чтобы удовлетворить будущие потребности всех трех корпораций, архитектуру POWER требовалось несколько изменить. Большинство процессоров POWER были многокристальными. Некоторое упрощение архитектуры сделало возможным создание дешевых однокристальных вариантов (иначе говоря, микропроцессоров). Кроме того, архитектура POWER не поддерживала многопроцессорные системы, так что и здесь понадобились соответствующие добавления. Были также увеличены возможности поддержки предполагаемых будущих приложений. Наконец, 32-разрядная архитектура POWER была расширена путем включения 64-разрядных адресов и операций. В результате всех этих изменений на свет появилась новая архитектура s PowerPC. Ее эволюция, начиная с 801, показана на рисунке 2.2.

Усилиями инженеров Apple, IBM и Motorola был создан новый проектный центр для разработки микропроцессоров PowerPC. Персонал Somerset Design Center, расположенного в Остине, состоит, в основном, из инженеров IBM и Motorola. В конце 1995 года Somerset стал частью подразделения IBM Microelectronics. Сотрудничающие фирмы имеют право производить и продавать процессоры, разработанные в Сомерсете. Например, Apple покупает микросхемы PowerPC как у IBM, так и у Motorola. Процессоры PowerPC Motorola производятся на заводе этой фирмы в Остине. IBM производит свои микросхемы PowerPC в Барлингтоне (Burlington), штат Вермонт.

Важно отметить, что RISC-процессоры в последние несколько лет неуклонно прогрессируют. Практически каждый их производитель, включая консорциум PowerPC, ныне поставляет на рынок 64-разрядный RISC-процессор, на кристалле которого установлена аппаратура динамического планирования, использующая описанный выше алгоритм Томасуло, а также предсказания переходов. Удивительно, но мы, кажется, совершили полный круг? В современные процессоры снова включена вся аппаратура, для устранения которой и была первоначально предложена RISC-архитектура. Сеймур Крей мог бы гордиться: ведь аппаратные решения, предложенные им впервые в 1964 году, взяли верх над более простыми архитектурами ранних RISC-процессоров. Это определенно не те RISC-процессоры, что раньше!

 

RISC-процессор AS/400 для коммерческих расчетов

В 1990 году была разработана новая архитектура RISC-процессора для будущих моделей AS/400. Первоначальная архитектура процессора, получившая неуклюжее название Internal Microprogrammed Interface (IMPI) была разработана в середине 70-х для System/38 и предназначалась для поддержки интерактивных коммерческих систем обработки транзакций.

IMPI была преимущественно архитектурой память-память. С помощью одной команды данные могли быть выбраны из памяти, изменены процессором и записаны обратно. Обычно, интерактивные приложения обработки транзакций перемещают много данных, но изменяют лишь их малую часть. Рассмотрим типичную операцию обновления инвентарной описи.

Пользователь делает заказ по телефону. Наше приложение должно обновлять инвентарную запись для каждой проданной им единицы товара. Инвентарная запись выбирается из памяти, или, что вероятнее всего, с диска. Размер заказа сравнивается с полем количества в записи, и если это количество достаточно, то оно уменьшается на число проданных единиц товара. Наконец, обновленная запись помещается обратно в память, и к ней может обратиться другой пользователь системы.

Описанная операция может считаться отдельной транзакцией, или быть частью более крупной транзакции. В любом случае, мы имеем дело с обработкой транзакций.

Кроме того, данное приложение интерактивно, так как им управляет человек за терминалом (приемщик заказа). Этому человеку исключительно важно получить ответ быстро. Следовательно, для создания интерактивной системы обработки транзакций абсолютно необходим процессор, который в состоянии перемещать большие объемы данных и выполнять операции в короткое время. AS/400 отлично подходит для приложений такого типа.

На протяжении многих лет мы исследовали тысячи коммерческих приложений, написанных для AS/400 и других многопользовательских систем Рочестера. Все они имеют ряд общих характеристик. Рассмотрим некоторые из них.

Возможность поддерживать параллельную работу сотен и даже тысяч пользователей.

Длинные последовательные цепочки команд, причем большая часть длины такой цепочки приходится на код операционной системы, а не приложения. Приложения выполняют множество обращений к операционной системе за различными видами обслуживания, например, для ввода-вывода.

Адресация структур данных в AS/400 выполняется посредством указателей, что требует использования целочисленной арифметики для обновления адресов.

При обработке данных используются, в основном, строковые или целочисленные сравнения, обновления и вставки. Арифметика с плавающей точкой используется редко.

Циклы в приложениях для AS/400 встречаются реже, а нециклические переходы чаще, чем в приложениях для научных расчетов.

Обрабатываемые данные разбросаны по большому объему дискового пространства. Объем данных, выбираемых за одно обращение к диску, относительно невелик, а последовательные обращения с большой вероятностью будут обращены к разным дискам.

Сравним приложение данного типа с типичным приложением для инженерных или научных расчетов, выполняемом на специализированной рабочей станции. Последние часто называют вычислительными (compute-intensive), так как они выполняют большие объемы вычислений с относительно малыми объемами данных. Обычно, такие приложения имеют малые рабочие наборы команд с большим числом компактных циклов вычислений с плавающей точкой. Ввод-вывод в них чаще последовательный, а не прямой. Сеймур Крей показал, что для приложений такого типа наилучшим будет процессор, который обрабатывает данные только в регистрах, как RISC-процессоры.

Коммерческие приложения по-прежнему преобладают, среди программ, написанных для AS/400. Но появляется все больше высокопроизводительных вычислительных приложений, что связано с переходом к модели клиент-сервер. В этой модели приложение разбивается между ПК или сетевым компьютером СК (клиент) и AS/ 400 (сервер). Серверные приложения ориентированы на увеличение числа операций, по сравнению с интерактивными приложениями. Приложения будущего, вероятно, потребуют еще большей вычислительной мощности.

С момента своего появления архитектура IMPI неоднократно расширялась и модифицировалась. Но даже и с учетом этих изменений ее нельзя признать подходящей для выполнения большого объема вычислений. Большинству специалистов в

Рочестере было ясно, что для удовлетворения будущих потребностей в вычислительной мощности необходимо введение характеристик RISC-процессора.

Итак, в 1990 году мы начали проект по добавлению к IMPI свойств RISC. Сначала мы хотели использовать процессор от RS/6000, но быстро отказались от этой мысли. Архитектура POWER была разработана для технических расчетов. Ей недоставало ряда характеристик, необходимых для выполнения коммерческих вычислений. Кроме того, она не могла обрабатывать большие объемы данных с требуемой эффективностью.

В то время RISC-процессоры были, как правило, 32-разрядными (то есть ширина трактов данных и регистров процессора равна всего лишь 32 битам). Большинство имело и 64-разрядные регистры с плавающей точкой, но целочисленные регистры — те, которые используются для коммерческих расчетов, — имели только 32 разряда. А так как RISC-процессор перед обработкой данных должен сначала загрузить их в свои регистры, то при больших объемах данных 32-разрядная ширина быстро становится недостатком. Архитектуры CISC, такие как IMPI, могут выполнять команды память-память, обрабатывая данные без загрузки их в регистры, таким образом, это узкое место здесь фактически обходится.

Приняв во внимание эти соображения, мы решили, что для нашего будущего компьютера необходим полностью 64-разрядный процессор. Дополнительно на нас влияло то, что ширина адреса в AS/400 равна 48 битам, и этот адрес невозможно втиснуть в 32-разрядный регистр. 64-разрядный процессор позволял нам расширить адрес, используемый в IMPI, с 48 до 64 бит. Наши расчеты показывали, что в будущем, по мере того как системы AS/400 будут становиться все больше и больше, настанет момент, когда потребуется больший размер адреса.

Нельзя было не брать во внимание и объем микрокода, который пришлось бы изменить. Начав с IMPI, мы смогли бы минимизировать эти изменения.

Итак, было принято решение: взять IMPI, расширить его до 64 бит и добавить вычислительные операции, присущие RISC. Нам предстояло создать первый гибридный процессор CISC/RISC, предназначенный исключительно для коммерческих вычислений. Мы назвали его C-RISC — «Commercial-RISC».

 

Технология PowerPC для AS/400

Президентом IBM в 1991 году был Джек Кюлер (Jack Kuehler). Он привел IBM к соглашению с Apple и Motorola о создании микропроцессоров PowerPC. Джек Кюлер считал, что к концу десятилетия все компьютеры, от самых маленьких, умещающихся на ладони, до суперЭВМ будут использовать RISC-процессоры. Он также полагал, что компании, создающие такие микропроцессоры, можно будет пересчитать по пальцам одной руки, и был твердо уверен, что альянс PowerPC станет одной из таких выживших фирм.

Кюлер не мог понять, почему обе его основные лаборатории одновременно занимаются разработкой новых RISC-процессоров. Лаборатория в Остине ра ботала над спецификацией PowerPC, а лаборатория в Рочестере s над C-RISC. I Кюлер был убежден в необходимости объединить усилия двух этих исследовательских центров, а также в том, что PowerPC подойдет и тем, и другим. Он стал выяснять, почему Рочестер не может использовать этот процессор. Мы покорно ездили в Армонк (Armonk), штат Нью-Йорк, где попытались объяснить различия между процессорами для коммерческих и научных расчетов. Кюлер не оспаривал успехи Рочестера, но и не принимал наши доводы. Он требовал дополнительные данные в обоснование нашей позиции. «Неужели RS/6000 не может выполнять и коммерческие вычисления?» — спрашивал он. Наконец, примерно после третьего визита в Армонк нам удалось его убедить.

Специалисты Рочестера знали, о чем говорят. Они понимали как делать процессоры для коммерческих вычислений, и чем эти процессоры отличались от предназначенных для технических расчетов. И все же Кюлер настоял, чтобы через 90 дней мы вернулись к нему с ответами на два вопроса: «Как изменить архитектуру PowerPC, чтобы она стала подошла для AS/400?» и «Сколько будет стоить перевод AS/400 на эту новую архитектуру?». Тем самым Кюлер дал нам возможность влиять на проект PowerPC. Он также изъявил желание финансировать любые дополнительные расходы, связанные с переходом на новый процессор.

В начале апреля 1991 года я возглавил группу из 10 человек, которая должна была дать ответ на оба эти вопроса. Кюлер также дал указание главе IBM Research, отвечавшему за согласование архитектуры PowerPC с Apple и Motorola, работать в тесном контакте с нами. Кроме того, наши инженеры тесно сотрудничали со своими коллегами из Остина.

Успех проекта во многом зависел от из рочестерской команды:, чьи инженеры были в числе самых лучших. Задача была не из легких. Сначала казалось, что требования AS/400 прямо противоположны задачам PowerPC. Затем возникло ощущение, что в результате слияния этих двух архитектур Рочестер лишится возможности создавать процессоры, оптимизированные для коммерческих расчетов. Нечего и говорить, как горячи были споры!

Было решено начать с архитектуры PowerPC в том виде, как она была определена на тот момент. К ней следовало добавить расширения, необходимые для AS/400. В результате должно было получиться нечто новое, заранее названное, в отличие от базовой архитектуры PowerPC, Amazon.

Хотя в Рочестере и были определенные сомнения в плодотворности идеи общей архитектуры RISC, тем не менее, ее разработка шла быстро. Основная роль здесь принадлежала Энди Уоттренгу (Andy Wottreng) и Майку Кор-ригану (Mike Corrigan). Они выполнили выдающуюся работу по интеграции технических требований AS/400 в новую архитектуру. В результате, впервые была создана архитектура RISC, которая одинаково хорошо подходила и для коммерческих, и для технических приложений.

За координацию проекта отвечал Дэррил Соли (Darryl Solie). Он находился в тесном контакте с обеими группами разработчиков в Остине и Рочесте-ре и обеспечивал взаимодействие между ними. Проектировщики Рочестера многому научились у инженеров других подразделений IBM и Motorola. Уровни производительности процессоров, которые сперва казались недостижимыми, внезапно становились возможными. В результате, сейчас в Рочес-тере создаются одни из самых быстрых процессоров в мире. Наша лаборатория отвечает внутри IBM за разработку новых 64-разрядных процессоров для коммерческих вычислений.

Всякий раз, когда возникали трения, разгорались споры, и кто-нибудь начинал утверждать, что порочна идея в целом, в дело вмешивался Билл Берг (Bill Berg). Спокойно, дипломатично и быстро убеждал нас в том, что мы s на правильном пути, и что только мы можем пройти его до конца. Позднее Билл способствовал тому, чтобы убедить разработчиков использовать при создании программного обеспечения новой операционной системы объектно-ориентированные технологии.

Архитектура PowerPC должна была работать как в 32-разрядном, так и в 64-разрядном режимах. Все 64-разрядные версии PowerPC должны были иметь и 32-разрядное подмножество. Мы сосредоточились только на 64-разрядном режиме, практически не изменив 32-разрядное подмножество.

По мере разработки новой архитектуры мы могли предварительно оценить ее стоимость. Работа велась напряженно и была завершена за 90 дней, но результаты не слишком впечатляли.

Многие из необходимых нам архитектурных изменений было бы трудно внести в ранние версии процессоров PowerPC, разработанные в Сомерсете. Процессоры поздних моделей AS/400 должны были обрабатывать очень большие объемы данных, и для нужной производительности требовались очень широкие шины данных. Мы даже не пытались ничего добавлять в конструкции процессоров PowerPC 601, 603 или 604, так как они поддерживали только 32-разрядный режим. Было также крайне сомнительно, сможем ли мы усовершенствовать первый разработанный в Сомерсете 64-разрядный процессор (его окончательное название s 620), так как плотность упаковки элементов на этом кристалле была недостаточна для того, чтобы сделать его подходящим для наших моделей — пришлось бы разработать многокристальную версию архитектуры.

Даже в отношении младших моделей AS/400 у нас не было полной ясности. Некоторое время мы предполагали применить усовершенствованный вариант 620, который мы назвали 621, но в конце концов решили, что проще всего разрабатывать процессоры для AS/400 внутри IBM.

Одновременно с нами разработчики RS/6000 также пришли к заключению, что не смогут использовать ранние версии процессоров PowerPC в своих старших моделях. Для младших моделей подходил однокристальный процессор разработанный в Сомерсете, но для более высокопроизводительных моделей требовался многокристальный процессор. Кроме того, наши коллеги хотели включить в свой проект некоторые коммерчески выгодные возможности технических вычислений, а именно, NIC (numerically intensive computing), большинство из которых отсутствуют в обычном PowerPC. Также было добавлено больше конвейеров и новые вычислительные команды. Созданное в результате расширение первоначальной архитектуры POWER получило название POWER2.

Впервые процессоры архитектуры POWER2 были применены в RS/6000 в 1993 году. Они также использовались в RS/6000 Scalable POWERparallel System (RS/6000 SP). Последняя система ознаменовала выход IBM на рынок компьютеров параллельных вычислений. В RS/6000 SP может работать параллельно много таких процессоров. Параллельные машины очень хороши для ряда научно-технических и некоторых коммерческих приложений, например, для просмотра больших баз данных.

Первоначально архитекторы AS/400 и RS/6000 хотели добиться общей конструкции процессоров, решив включить в архитектуру Amazon все необходимые для них расширения. Мы планировали создать один процессор, который мог бы поддерживать специфические требования обеих систем.

У первого общего процессора PowerPC, предназначенного как для AS/400, так и для RS/6000, было несколько названий. Разработчики RS/6000 часто называли его POWER3, или PowerPC 630. Мы дали ему внутреннее имя Belatrix. Беллатрикс s это звезда в созвездии Ориона. Немногие знают, что ее называют также звездой Амазонки (Amazon Star). Belatrix должен был стать звездой архитектуры Amazon.

Как и многие предыдущие проекты, проект Belatrix был слишком амбициозным и всеохватывающим и не имел успеха. Мы решили, что целесообразнее иметь несколько версий процессоров PowerPC, оптимизированных для разных вычислительных сред. Каждый процессор PowerPC должен был реализовывать базовый набор команд и функций, а также поддерживать необязательные расширения.

Рочестер должен был сделать первые процессоры PowerPC применимыми для коммерческих задач. Первоначально они предназначались исключительно для AS/400.

Позже было принято решение: начиная с 1997 года использовать новое поколение 64-разрядных процессоров PowerPC, разработанных в Рочестере, и для RS/6000.

После прекращения работ над Belatrix в Остине начали разработку новой версии 630 — 64-разрядного процессора PowerPC, который должен был обеспечить вычислительную производительность, необходимую для будущих систем. Мы в Рочестере также стали разрабатывать свою версию Belatrix, которая предназначалась для серии AS/400 1998 года. Так как Belatrix назван по имени звезды, а Миннесота известна как штат Серверной звезды (North Star), то мы назвали новый процессор Northstar.

В области программного обеспечения ситуация с PowerPC была гораздо хуже, по сравнению с тем, что мы обещали Кюлеру. Все прикладное и системное программное обеспечение, работавшее поверх MI, было защищено благодаря независимой от технологии архитектуре AS/400. Однако, поскольку PowerPC сильно отличается от IMPI, то микрокод, расположенный ниже MI, было необходимо переделать под новый процессор. Это нелегкая задача, несмотря на то, что часть ее можно было осуществить с помощью автоматизированных средств. Между тем наши программисты должны были заниматься выпуском новых версий AS/400. Мы подсчитали, что для работы с RISC-процессором потребуется нанять несколько сотен новых системных программистов.

Наконец, мы были ограничены по времени. Первоначально планировалось выпустить новые процессоры C-RISC в середине 1994 года, мы уже мечтали о них для Advanced Series. При использовании PowerPC нам пришлось бы изменить планы и передвинуть выпуск RISC-процессоров на 1995 год s именно столько времени потребовалось бы для разработки нужных расширений и переписывания внутреннего кода. Пришлось бы оснащать Advanced Series процессорами IMPI и обеспечить возможность их модернизации процессорами PowerPC, когда последние будут готовы.

В начале июля 1991 года мы вновь нанесли визит Джеку Кюлеру. Большинство из нас полагали, что он поблагодарит за проделанную работу, сделает вывод, что переход на процессор PowerPC будет слишком дорогим и отправит обратно заниматься созданием C-RISC. Но Кюлер ничего такого не сделал. Вместо этого он попросил нас ускорить работу и предоставил необходимые для этого ресурсы. Так, внезапно для нас, пришлось полностью изменить направление работ над Advanced Series как в области аппаратного, так и программного обеспечения.

В конце июля мы завершили реорганизацию лаборатории для работы над новой системой. Ответственность за разработку новой модели процессора, названной Muskie, была возложена на Рочестер. Этот многокристальный процессор был предназначен для коммерческих вычислений на очень больших компьютерах. Разработка младших моделей серии AS/400 была переведена в лабораторию IBM в Эндикот-те. Эта линия получила наименование Cobra, и ее процессоры должны были быть однокристальными и полностью 64-разрядными.

Как уже упоминалось, первоначально мы планировали только 64-разрядный режим процессора. В конце концов, AS/400 не использует 32-разрядный режим, да и никто более не собирался использовать ранние 32-разрядные процессоры, так что реализовывать эту архитектуру в полном объеме, как нам казалось, не имело смысла. Но примерно через год, когда стало ясно, что AS/400 необходимо поддерживать все прикладное программное обеспечение, написанное для процессоров PowerPC, это решение было изменено. Поскольку большая часть таких программ написана для 32-разрядных процессоров, то и нам пришлось включить во все свои процессоры 32-разрядное подмножество. Это также должно было обеспечить возможность использовать наши новые PowerPC на других системах IBM.

Одновременно активизировалась работа по переносу микрокода AS/400 на новые процессоры. Это была возможность ревизии внутренностей операционной системы AS/400, чего не делалось с момента разработки System/38. Поскольку мы собирались перекраивать самые основы, то было решено идти до конца и использовать новейшие объектно-ориентированные методологии программирования. Мы планировали получить самую современную операционную систему.

За организацию работ по переделке основ операционной системы отвечал Майк Томашек (Mike Tomashek). Майк знал, что у него нет ни людей, ни W опыта для того, чтобы уложиться в отведенные сроки. Любой здравомыслящий человек подтвердил бы, что это невозможно. Вместе с ключевыми раз-1 работчиками, такими как Билл Берг и Крис Джонс (Chris Jones) Майк разработал план. Им было нужно нанять сотни новых людей, обучить их объектно-ориентированным технологиям и переписать важнейшие части операционной системы AS/400 за короткие сроки. Майк не потратил много времени на раздумья и дебаты. Он просто объявил, что план сработает, и на полной скорости двинулся вперед.

В конце 1991 мы начали массовый найм программистов. В ряде крупнейших газет Америки стали появляться объявления о том, что в Рочестере требуются системные программисты с опытом работы на С++. Нам удалось быстро нанять несколько сотен новых программистов. Тогда многие обозреватели удивлялись, для чего нам это понадобилось, но теперь они знают.

Прежде чем перейти к более подробному рассмотрению архитектуры PowerPC, хочу напомнить о нашей «перечной» системе рейтинга. Оставшаяся часть этой главы — лишь для тех, кому нужны дополнительные подробности. Обратите внимание, что когда мы начнем обсуждение реализации процессора, материал станет еще «острее». Если «попробовав этой информации Вы найдете ее «чересчур», просто пролистайте книгу, пока не дойдете до тех разделов, где меньше специй.

 

Архитектура PowerPC

Архитектура PowerPC обладает всеми обычными характеристиками архитектуры RISC: команды фиксированной длины, операции регистр-регистр, простые режимы адресации и большой набор регистров. Но есть и характеристики, отличающие ее от

других.

Как уже упоминалось, архитектура PowerPC — полностью 64-разрядная с 32-разрядным подмножеством. Она допускает как 32-разрядные, так и 64-разрядные версии процессоров PowerPC, но все они должны поддерживать, как минимум, 32-разрядное подмножество. Архитектура определяет переключатель режима 32/64, которые может использоваться операционной системой, чтобы позволить 64-разрядному процессору выполнять 32-разрядные программы.

В основе набора команд лежит идея суперскалярной реализации. В суперскалярном процессоре за один такт несколько команд могут быть распределены на несколько конвейеров. Аппаратура процессора просматривает поток команд и отправляет на выполнение максимально возможное число независимых команд (обычно от двух до четырех за цикл). Эти команды могут далее выполняться параллельно и даже завершиться в порядке, отличном от первоначального. Такой дополнительный параллелизм может значительно увеличить общую производительность процессора.

Команды направляются одновременно в три независимых исполняющих блока. Общая структура PowerPC показана на рисунке 2.3: блок переходов, блок фиксированной точки и блок плавающей точки. Также показан кэш команд, кэш данных, память и пространство ввода-вывода, которое в данной архитектуре выглядит как часть памяти.

Рисунок 2-3 Модель архитектуры PowerPC

Для каждого исполняющего блока архитектурой определен независимый набор регистров. Любая определенная архитектурой команда может выполняться только одним типом управляющих блоков. Таким образом, у каждого блока собственный набор регистров и собственный набор команд. Эти исполняющие блоки часто называют процессорами, так как им присущи все характеристики процессора. Можно считать, что процессор PowerPC содержит три отдельных процессора s исполняющих блока. При этом каждый исполняющий блок может иметь несколько конвейеров команд. Если, например, для модели, оптимизированной для вычислительных задач, важна производительность операций с плавающей точкой, то блок плавающей точки может содержать два и более конвейеров и, таким образом, выполнять более одной команды плавающей точки одновременно. То же самое верно и для двух других блоков. В принципе, возможно создать процессоры PowerPC, способные выполнять пять и более команд одновременно.

Преимущество такой схемы не только в одновременном выполнении нескольких команд, но также и в минимальной необходимости взаимодействия и синхронизации между блоками, что достигается благодаря наличию у каждого блока отдельных ресурсов. Исполняющие блоки могут подстраиваться под изменяющийся поток команд, позволять командам обгонять друг друга и завершаться в ином порядке.

Другая характеристика архитектуры PowerPC, отличающая ее от обычного RISC-процессора s использование нескольких составных команд. Самой большой недостаток RISC по сравнению с CISC — увеличение объема кода. Для выполнения одной и той же программы RISC требуется больше команд, чем CISC. Составные команды позволяют уменьшить это разрастание кода. Некоторые из них очень просты, например, обновление регистра базы при загрузке и сохранении, что позволяет исключить дополнительную команду прибавления. Другие более сложны, например, команды множественной загрузки и сохранения, позволяющие перемещать значения нескольких регистров одной командой. Есть также команды загрузки/сохранения цепочек, которые позволяют загружать и сохранять произвольно выровненную цепочку байтов. Фанатики CISC узнают в последней паре команд не слишком хорошо замаскированные команды пересылки символов.

Ортодоксы RISC негодуют и обвиняют архитекторов PowerPC в том, что они «продались» сторонникам CISC. На самом же деле, надо просто понять, что в реальности некоторые операции, такие как пересылка невыравненных строк байтов, происходят достаточно часто и требуют определенной оптимизации. Если составная команда дает то, что нужно, даже нарушая при этом какое-то неписаное правило «чистого» RISC, то пусть так и будет. Составные команды не означают возврата к архитектуре CISC, однако их применение в RISC-процессорах лишний раз доказывает, что в мире нет ничего абсолютно белого или черного.

Интенсивное применение суперскалярных возможностей и использование составных команд составляют философию проектирования архитектуры PowerPC. Эта философия используется также и другими архитектурами, такими как Sun SuperSPARC и Motorola 88110. Есть мнение, что такая сложность затрудняет достижение процессорами высоких тактовых частот, обычно измеряемых мегагерцами (МГц). Сторонники этой точки зрения полагают, что большая производительность может быть достигнута скорее за счет высокой тактовой частоты, а не интенсивного параллелизма на уровне команд.

Что такое МГц? В последние годы стало популярным выражать производительность микросхемы процессора ЭВМ с помощью этой единицы измерения. Для простоты восприятия, ее можно соотнести с оборотами в минуту автомобильного двигателя: эта величина показывает, насколько быстро вращается двигатель автомобиля, или сколько оборотов в минуту совершает коленчатый вал. Скорость процессора можно рассматривать как число тактов, которое он может выполнить в секунду. За один такт процессор обычно может выполнить одну простую команду, так что иногда данная величина воспринимается как приблизительное число команд, выполняемое процессором в секунду. Физическая единица герц (Гц) получила свое название в честь немецкого физика и равна одному циклу в секунду. Один мегагерц (Mrii)s это миллион циклов в секунду.

Философию высокой тактовой частоты можно проиллюстрировать и примерами архитектур Digital Alpha, HP PA-RISC и MIPS R4000. Возьмем, например, PA-RISC 1.1. Этот процессор обычно выполняет две команды за такт. Менее мощные модели PowerPC могут за такт исполнять три команды, тогда как старшие модели s четыре и более. Этот дополнительный параллелизм дает PowerPC выигрыш в производительности, хотя и за счет увеличения сложности, что может снизить тактовую частоту.

Спор о том, какая из этих двух точек зрения лучше, продолжается. Противоборствующие лагеря условно можно назвать «Speed Daemons» (высокая тактовая частота) и «Brainiacs» (сложность). Суть вопроса в том, что тактовая частота, измеряемая мегагерцами, не всегда адекватно отражает общую производительность процессора. 150 МГц Brainiac может легко превзойти по производительности 300 МГц Speed Daemon. Все зависит от выполняемой программы и степени параллелизма команд, которой может достичь компилятор.

Некоторые новости указывают на то, что чаша весов склоняется на сторону архитектур Brainiac, таких как PowerPC. Судя по описанию, новая архитектура HP, получившая название PA-RISC 2.0, выглядит так, словно ее создатели поддались зову сирены сложности. Так как архитектура PA-RISC 2.0 остается процессор- ориентированной, то как объявлено HP, 64-разрядные приложения для новой аппаратуры появятся примерно через 3-5 лет.

 

Расширения архитектуры PowerPC

Так как первое поколение процессоров PowerPC создавалось специально под AS/400 и не было PowerPC в полном смысле, мы решили дать этим процессорам новое название s PowerPC Optimized for the AS/400 Advanced Series, но так как это труднопроизносимо, решено было остановиться на более кратком варианте s PowerPC AS. Большинство расшифровывают AS как Advanced Series, но многие из нас предпочитают считать, что это Amazon Series. Во втором поколении наших процессоров, представленном в 1997 году, мы реализовали и полную архитектуру PowerPC, и все расширения. Так как те же самые процессоры используются RS/6000, то обозначение AS более не имеет смысла. Самое существенное новшество архитектуры для AS/400 — использование тегов памяти (memory tags), которые будут подробно рассмотрены в главе 8. А вкратце мы поговорим об этом прямо сейчас.

В System/38 была реализована концепция одноуровневой памяти. Проще говоря, вся память, включая дисковую, представляет собой большое единое адресное пространство. Нам был необходим эффективный механизм защиты памяти от пользователей, не имеющих права доступа к ним. В MI адресация выполнялась с помощью 16-байтовых указателей. Указатель содержит некоторый адрес, и пользователь может этот адрес изменить (подробнее об этом будет рассказано в главе 5). Поскольку адрес после изменения может указывать на любую область памяти, необходимо предотвратить неавторизованные изменения адресов пользователями.

С каждым словом памяти System/38, имеющим 32 разряда данных, связан специальный бит защиты памяти, называемый битом тега (tag bit). Указатель MI занимает четыре таких слова. Всякий раз, когда операционная система сохраняет в четырех последовательных словах памяти указатель, аппаратура включает (устанавливает в 1) четыре бита тега, для индикации того, что указатель содержит адрес, допустимый для данного пользователя. Если пользователь изменяет в памяти любую часть указателя, то аппаратура выключает (устанавливает в 0) бит тега. Если хотя бы один из битов тега сброшен, то адрес в указателе неверен и не может быть использован для доступа к памяти.

В целях безопасности бит тега не может быть одним из битов данных внутри слова, так как последние пользователь может видеть и изменять. Он должен быть скрытым, то есть храниться в недоступной пользователю области памяти, но где именно?

System/38 использует для каждого слова памяти биты кода коррекции ошибок. Содержащая их часть памяти невидима программам, работающим поверх MI. Мы решили добавить к битам кода коррекции ошибок еще один и использовать его как бит тега. При изменении слова памяти какой-либо пользовательской программой, процессор должен автоматически сбрасывать скрытый бит тега. Ведь если данное слово станет частью указателя, то тот будет неверным. Только микрокод расположенный ниже MI имеет команды для включения битов тега.

В памяти AS/400 также используются биты тега. Поскольку в архитектуре PowerPC таковые не предусмотрены, нам пришлось добавить к ней режим активных тегов (tags-active mode). В этом режиме процессор «знает» о битах тега и будет сбрасывать их всякий раз, когда пользователь изменяет слово в памяти. Все процессоры AS/400 работают в режиме активных тегов. Существующие процессоры PowerPC используют режим неактивных тегов.

 

65-разрядный процессор?

В AS/400 ширина слова памяти возросла до 64 разрядов данных. С каждой восьмеркой байтов памяти AS/400 связан бит тега и указатель MI, занимающий два таких слова. В 1991 году нам виделись некоторые преимущества в том, чтобы хранить два теговых бита в регистрах новых RISC-процессоров, так же как и в памяти. Кроме того, мы хотели сократить размер указателей MI до 8 байтов. Внутри 16-байтовых указателей было неиспользуемое пространство, и казалось, что как раз настал подходящий момент сжать их.

Для того чтобы хранить такие тегированные указатели в регистрах, размер целочисленных регистров нужно было увеличить до 65 разрядов. Мы разрабатывали описанную схему около года, но в 1992 году отказались от нее и вернулись к решению, хранить теги только в памяти. На то было три основных причины. Во-первых, изменение размера указателя влияло на OS/400 и требовало слишком многих модификаций ее кода. Во-вторых, такой подход ограничивал будущие расширения размера адреса 64 разрядами. И третье, самое важное — процессоры в режиме активных тегов оказались бы несовместимы с набором команд PowerPC.

Первоначально мы не считали совместимость с PowerPC важной. Будущие процессоры, реализующие режим неактивных тегов, где 65-й разряд игнорируется, были бы полностью совместимы с PowerPC. А реализация 32-разрядных команд в режиме активных тегов и соответствующее программное обеспечение не планировалась даже в начале проекта. Ведь предполагалось, что этот режим будет использоваться только операционной системой AS/400, которая имеет дело с 64-разрядными командами.

Затем, когда было решено поддерживать совместимость с набором команд PowerPC, мы избавились от 65-го разряда в процессоре. Тогда намечалось некое слияние операционных систем IBM (см. Приложение). В рамках этого проекта предполагалось и программное обеспечение, большая часть которого предназначалась для 32-разрядного процессора. Поэтому мы обеспечили поддержку 32-разрядного набора команд всеми процессорами даже в режиме активных тегов. Наши процессоры второго поколения имеют режимы как активных, так и неактивных тегов и могут исполнять все прикладное и системное ПО PowerPC.

Хотя мы вернулись к 64-разрядным процессорам уже много лет назад, даже в IBM есть люди, по-прежнему упоминающие 65-разрядные, которые так никогда и не были созданы. Эта путаница возникает потому, что многие не знают, что собственно делает бит тега. Вероятно, если бы мы назвали его «битом защиты указателя в памяти» (pointer in memory protection), то не ввели бы в заблуждение столько народу. Но боюсь, тогда бы нам пришлось все время объяснять, зачем нам понадобился «бит pimp».

 

Система команд Amazon

Архитектура PowerPC определяет привилегированные операции и команды, используемые только операционной системой и не предназначенные для прикладных программ. В AS/400 после специальных расширений этим «ведает» режим активных тегов. Например, механизм трансляции адреса должен поддерживать и одноуровневую память с единым адресным пространством, и обычную память с отдельным адресным пространством для каждого процесса. Мы используем режим активных тегов для того, чтобы приказать процессору использовать одноуровневую память. В режиме неактивных тегов процессор использует обычную трансляцию адреса PowerPC.

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

А сейчас хочу привести некоторые цифры. Они помогут подытожить разговор об изменениях в архитектуре AS/400 и связанных с ними перспективах развития архитектуры PowerPC.

32-разрядная архитектура PowerPC определяет 187 команд, причем 11 из них — необязательные.

64-разрядная архитектура PowerPC определяет 228 команд (187 из 32-разрядного набора + 41 дополнительная), из них 21 — необязательная.

Архитектура Amazon определяет 253 команды (228 из 64-разрядного набора PowerPC + 25 дополнительных), из них 20 — необязательные. Заметьте, что 25 дополнительных команд доступны только в режиме активных тегов. Режим неактивных тегов поддерживает лишь 64-разрядный набор команд PowerPC. Но учтите, что определение любой архитектуры динамично и конкретные числа могут изменяться!

 

Реализации процессора AS/400

Первые использовавшиеся в AS/400 RISC-процессоры поддерживали только режим активных тегов и только структуру ввода-вывода AS/400. Поэтому они выполняли приложения, но не операционные системы, написанные для стандартного процессора PowerPC. Любая другая операционная система на одном из этих процессоров для таких функций как ввод-вывод должна пользоваться средствами, предоставляемыми операционной системой AS/400. (Подробнее об этом — в следующих главах).

Последнее поколение RISC-процессоров для AS/400е поддерживает и режим активных тегов, и режим неактивных тегов, а, кроме того, обе структуры ввода-вывода одновременно. Они способны исполнять любую ОС для PowerPC и используются как в серии AS/400е, так и в RS/6000. Процессоры будущего сохранят эти характеристики.

 

Процессоры Muskie первого поколения

Процессор первого поколения, известный под названием Muskie, был разработан в Рочестере в 1995 году как старшая модель процессора для AS/400. На тот момент он был самым быстрым процессором PowerPC и самым быстрым микропроцессором IBM. Первоначально он имел время цикла 6,5 наносекунд, что соответствует тактовой частоте 154 МГц. В 1996 году мы представили еще более быстрые его версии со временем цикла 5,5 наносекунд (182 МГц).

Muskie явно предназначен для использования в системах коммерческих расчетов, а не в технических рабочих станциях. И хотя это не самая последняя наша разработка PowerPC, его стоит рассмотреть подробнее, чтобы понять различия между процес

сорами, предназначенными для коммерческих и научно-технических расчетов. Тогда станет ясно, почему было решено сконцентрировать усилия Рочестера на разработке процессоров для коммерческих вычислений (и для AS/400, и для RS/6000), тогда как Остин занимается процессорами для научно-технических расчетов.

Процессор Muskie — одномодульный, многокристальный, конвейерный, суперскалярный и предназначен для старших RISC-моделей AS/400. Это единственный многокристальный процессор семейства PowerPC. Процессор построен по четырех-канальной (4-way) суперскалярной схеме, то есть может выбирать и исполнять до четырех команд за цикл. Кроме того, поддерживаются и многопроцессорные конфигурации.

Рисунок 2.4 Структурная схема процессора Muskie

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

Все шесть кристаллов Muskie используют технологию БиКМОП (Биполярный-КМОП). Биполярная технология имеет высокое быстродействие (в этом ее преимущество) и потребляет большую мощность. Недостаток БиКМОП — большое выделение тепла. Из-за объема рассеиваемого тепла биполярные кристаллы не могут использовать столь же высокую плотность упаковки, как кристаллы КМОП. Технология БиКМОП позволяет размещать на одном кристалле как биполярные цепи (для внешних усилителей), так и цепи КМОП (для схем внутри кристалла).

Вместе со всеми вспомогательными схемами процессор Muskie занимает семь кристаллов. Последние упакованы в один многокристальный модуль, насчитывающий более 25 миллионов транзисторов. Один из кристаллов управляет вводом-выводом, то есть технически не является частью процессора. Прочие шесть кристаллов, составляющих процессор, вместе с соединениями между ними показаны на рисунке 2.4.

БиКМОП отлично подходит для многокристального процессора. Например, известный Intel Pentium Pro выполнен в виде двухкристального модуля и использует технологию БиКМОП по тем же причинам, что и Muskie.

Чтобы понять, почему для реализации данной технологии требуется так много транзисторов, рассмотрим микросхемы процессора подробнее.

В состав шести основных кристаллов, составляющих процессор, входят кристалл процессорного блока PU (Processing Unit), кристалл блока плавающей точки FPU (Floating-Point Unit) и четыре одинаковых кристалла блоков управления основной памятью MSCU (Main Store Control Unit). На кристалле PU расположены кэш команд, блок переходов и блок фиксированной точки. Кэш команд размером 8 килобайт имеет ширину 32 байта. Он может выбирать из памяти за один такт 32 байта (8 команд). Для передачи больших объемов данных за один такт имеются 32-байтовые тракты данных. Даже регистровый стек блока фиксированной точки рассчитан на загрузку или сохранение четырех 64-разрядных регистров за один такт.

FPU размещается на отдельном кристалле и поддерживает стандарт IEEE для операций с плавающей точкой. Он спроектирован так, что способен выдавать результат в каждом такте, обеспечивая очень высокую производительность команд с плавающей точкой. Четыре команды за такт передаются от кристалла PU на кристалл FPU по 16-байтовой P-шине. Все данные, хранимые в памяти, также пересылаются из PU по P-шине в кэш данных. Данные для FPU выбираются из кэша данных со скоростью 32 байта за такт. Данные из FPU и PU пересылаются в кэш данных по 16-байтовой шине сохранения.

MSCU содержит кэш данных, а также интерфейс памяти. Все четыре кристалла совместно реализуют 256-килобайтовый кэш данных и интерфейсы к шинам данных (см. рисунок 2.4). Обращения к кэшу данных выполняются конвейерно, так что за каждый такт считываются 32 и сохраняются 16 байт данных. MSCU поддерживает многопроцессорные конфигурации, обеспечивая когерентность кэшей разных процессоров.

PU и FPU вместе насчитывают 5 конвейеров, однако в каждом цикле может быть распределено только 4 команды, а именно:

команда перехода (включая операцию над содержимым регистра условия);

команда загрузки/сохранения;

команда арифметики с фиксированной точкой;

команда фиксированной точки (логическая, сдвиг или циклический сдвиг; или команда плавающей точки).

Команды плавающей точки исполняются в FPU, но не могут быть выбраны на выполнение одновременно с командами фиксированной точки для логических операций, сдвига или циклического сдвига, выполняемыми в PU. Обратите внимание, что конвейер загрузки/сохранения выполняет выборку и запись данных как с фиксированной, так и с плавающей точкой. Несколько конвейеров выполняют фрагменты нескольких команд одновременно.

Процессор Muskie также может работать с разделяемой памятью, и таким образом поддерживает симметричное мультипроцессирование. Muskie первого поколения поддерживал конфигурации до 4 процессоров.

Будучи самым быстрым RISC-процессором IBM своего времени, Muskie оптимизирован для нужд коммерческих вычислений. Для иллюстрации приведем некоторые характеристики.

Системы и серверы для коммерческих расчетов должны обрабатывать огромные объемы данных. 16-байтовые (128 бит) и 32-байтовые (256 бит) шины позволяют Muskie справляться с этими задачами. Для сравнения: типичные 8-байтовые (64-разрядные) шины, используемые большинством высокопроизводительных RISC-процессоров, предназначены для рабочих станций, где объем обрабатываемых данных гораздо меньше.

Кэш — обычно слабое место большинства RISC-процессоров, даже если система способна перемещать большие объемы данных. Для устранения этого недостатка в Muskie предусмотрен 256-килобайтовый кэш данных, работающий за один цикл.

Поскольку команда перехода может вызвать простой конвейера, современные RISC-процессоры, подобно суперЭВМ, реализуют некоторую разновидность предсказания переходов. Для большинства RISC-процессоров точность предсказания переходов при выполнении технических задач составляет 80-90 процентов, благодаря тому, что в технических задачах процессор многократно повторяет последовательность команд тела цикла. Для программ подобного типа предсказание переходов работает отлично. В программах для коммерческих задач циклов гораздо меньше и точность предсказания переходов может быть ниже 50 процентов (это соответствует точности случайного выбора). Поэтому, вместо того чтобы пытаться угадать место перехода, Muskie выбирает команды из обоих мест перехода и начинает выполнять их. Данный метод, называемый спекулятивным выполнением (speculative execution), требует очень скоростного кэша (чем Muskie обладает), но зато позволяет достичь по сути стопроцентной точности на задачах любого типа.

Еще один важный аспект коммерческих вычислений — высокие требования к целостности данных и коэффициенту готовности. Muskie реализует коды коррекции ошибок для всех связей за переделами кристаллов. Кроме того, большая часть логики управления и передачи данных на каждом кристалле также содержит различные схемы контроля. Типичный же RISC-процессор для рабочей станции вряд ли способен на что-либо подобное в области определения и исправления ошибок.

 

Процессоры Cobra первого и второго поколения

Как и Muskie, процессоры Cobra имеют расширенную 64-разрядную архитектуру PowerPC. Они суперскалярные, что позволяет использовать параллелизм на уровне команд. Функционально оба семейства процессоров исполняют один и тот же набор команд уровня приложений. Некоторые различия между ними заключаются в реализации необязательных команд. Так Cobra предназначается для средних и младших моделей AS/400, поэтому реализация команд, поддерживающих, например, мульти-процессирование, в нем не предусмотрена.

Все четыре модели процессоров Cobra разработаны в Эндикотте. В системах AS/ 400, объявленных в 1995 году, используются Cobra-4 и Cobra-CR (CR расшифровывается как «cost reduced» — «цена уменьшена»). Cobra-CR — это Cobra-4, но с возможностью работать только на частоте 50 МГц, самой низкой для этого процессора.

Специально для тестирования нового программного обеспечения операционной системы команда проектировщиков в Эндикотте разработала вариант Cobra-0. Он никогда не применялся в AS/400.

Существовала также версия Cobra-Lite, названная так, поскольку в ней отсутствуют 17 обязательных команд PowerPC. Ее разработала небольшая группа из Рочестера для системы Advanced 36, анонсированной в 1994 году.

При разработке процессоров Cobra ставилась задача объединить процессор и интерфейс памяти на одном кристалле, который, в результате, содержит 4,7 миллиона транзисторов. Интерфейс шины ввода-вывода располагается на отдельном кристалле, что позволяет использовать процессор с разными интерфейсами ввода-вывода. Cobra использует КМОП, а не БиКМОП, а точнее — технологию, названную IBM CMOS-5L. В результате, процессор рассеивает меньше тепла, чем Muskie, и меньше его нуждается в охлаждении. Только процессоры Cobra помещаются в корпуса небольшого размера, изготовленные для Advanced Series в 1994 году.

Подобно Muskie, Cobra имеет 5 конвейеров, но за один цикл может распределять не более трех команд (то есть выполнен по трехканальной суперскалярной схеме). Это команды:

перехода (включая команду регистра условия);

загрузки/сохранения;

арифметики с фиксированной точкой (включая логические команды, команды сдвига и циклического сдвига), или команда плавающей точки, или команда регистра условия.

Три конвейера (фиксированной точки, плавающей точки и команд регистра условия) совместно используют третий слот диспетчирования команд.

Первые процессоры Cobra работали на тактовых частотах 50 и 77 МГц, но их конструкция, как уже упоминалось, допускает и более высокие частоты. Для поддержания подобной скорости Cobra имеет 4-килобайтный внутренний (на кристалле) кэш команд и 8-килобайтный (также внутренний) кэш данных. По сравнению с Muskie, это не очень много. Большой кэш трудно разместить в однокристальном процессоре, поэтому процессоры, подобные Cobra, используют иерархию кэшей. Маленькие внутренние кэши (называемые кэшами первого уровня или кэшами L1) дополняются большим по размеру внешним кэшем (кэш второго уровня или L2). Cobra может работать с внешним (на отдельной микросхеме) кэшем L2 размером 1 мегабайт.

 

Процессоры третьего поколения Apache

Модели AS/400 1997 года используют новый дизайн процессора. Этот однокристальный процессор PowerPC, разработанный в Рочестере и названный Apache. Он предназначен для средних и старших моделей AS/400е. Младшие модели серии по-прежнему используют процессор Cobra.

Apache можно считать процессором третьего поколения. В его основе — процессор Cobra, улучшенный и оснащенный новыми возможностями, например поддержки многопроцессорных систем. Apache — первый однокристальный процессор AS/ 400, которому по силам поддержка конфигурации SMP до 12 процессоров (даже Muskie поддерживал лишь четырехпроцессорные конфигурации).

В отличие от Cobra или Muskie, Apache полностью реализует архитектуру PowerPC. Он использует режим активных тегов для поддержки одноуровневой памяти AS/400 и режим неактивных тегов — для поддержки стандартной модели адресации PowerPC; а также стандартные шины адреса и данных PowerPC 6хх — для соединений за пределами кристалла. Так что Apache можно использовать с любой вспомогательной микросхемой, разработанной для семейства процессоров PowerPC 6хх. (О том, как это позволило преобразовать структуру ввода-вывода компьютеров серии AS/400е мы поговорим подробней в главе 10). Apache — первый из когда-либо разработанных в Рочестере процессоров, который может использоваться вне рочес-терских систем. Процессоры Apache используются как в RS/6000, так и AS/400е.

Рисунок 2.5 Структурная схема процессора Apache

Как и Cobra, Apache — однокристальный, 64-разрядный суперскалярный RISC-процессор (его структурная схема — на рисунке 2.5). Он реализован по новейшей технологии IBM CMOS-5S, что позволяет достичь большей плотности упаковки на кристалле, а также времени цикла в 8,0 наносекунд (125 МГц), хотя в некоторых моделях AS/400е используются более медленные версии. Технология КМОП значительно сокращает объем рассеиваемого тепла, который нужно отводить от процессора. В результате, на одной плате может быть установлено до четырех процессоров Apache.

В новом процессоре наиболее значительны изменения в подсистеме памяти. О том, как системы с Apache используют совершенно новую подсистему памяти, предназначенную для пересылки больших объемов данных без замедления работы, читайте в следующем разделе.

Несмотря на то, что время цикла у Apache не столь мало как в Muskie, новая подсистема памяти повышает масштабируемость Apache для конфигураций SMP, что позволяет создать еще более производительные модели AS/400е.

Прежде чем продолжить сугубо технический разговор, хочу представить вам новые корпуса, появившиеся вместе с процессорами Apache. Три оригинальных черных корпуса AS/400 Advanced Series (известные как Apex, Cedar Key и Key Largo) были заменены на два новых, также черных, корпуса (Millennium и Mako). Корпус для Advanced Entry (Eiger) остался тем же.

Мы изменили дизайн корпуса по нескольким причинам. Средние модели серии AS/400 поддерживают конфигурации SMP. Корпус Millennium допускает установку до четырех процессоров Apache, а корпус Mako для старших моделей — до 12 процессоров. (В прежний корпус для старших моделей (Key Largo) помещалось до четырех процессоров Muskie). Корпус Mako гораздо выше (около полутора метров, напоминает оригинальные белые стойки AS/400) и кроме дюжины процессоров в нем есть место для большего объема основной памяти и большего числа дисков. Новые корпуса, которые предполагается использовать в серии AS/400е до 2000 года, были разработаны совместно с подразделением RS/6000 для оптимизации общности компонентов этих систем.

 

О Процессоры четвертого и следующих поколений

Итак, мы рассмотрели процессор Muskie и то, каким образом он производит коммерческие вычисления, обрабатывая большие объемы данных. Четырехканальная суперскалярная архитектура, а также шины шириной 16 байт (128 бит) и 32 байта (256 бит) ясно свидетельствуют, что Muskie создан для обработки больших объемов данных и команд. А теперь представьте себе, процессор Muskie, упакованный вместе с набором 64-килобайтных кэшей для команд и данных в одну микросхему КМОП. Добавьте к этому полную архитектуру PowerPC процессора Apache и возможность поддерживать конфигурации с 12 или даже 16 процессорами. Что получилось? Конечно, это наш процессор четвертого поколения Northstar.

Сегодня можно уверенно сказать, что через несколько лет на первый план выйдут однокристальные КМОП-процессоры, помещенные в новые черные корпуса. Мы также знаем, что они будут использовать преимущества новой подсистемы памяти, впервые появившейся в Apache.

А впрочем, давайте отложим обсуждение процессоров будущего до главы 12. Там мы рассмотрим некоторые новейшие технологии, включая те, которые сегодня разрабатывает IBM для процессоров AS/400.

 

О Подсистема памяти

Одна из самых больших проблем любого процессора — обеспечение его загрузки. За последние несколько лет производительность процессоров необычайно выросла, в среднем удваиваясь каждые два года. Производительность памяти и ввода-вывода не успевает за этими темпами.

В 1991 году я купил новую IBM PC для домашних нужд. В ней был установлен процессор Intel 386 20 МГц, 70-наносекундная память и жесткий диск с временем доступа 16 миллисекунд. Маломощный процессор 386 не долго меня устраивал; поэтому я, как и многие другие, начал бесконечную гонку за новейшей аппаратурой, приобретая последовательно системы с процессорами 486 и Pentium. В последнем купленном мною компьютере (который уже тоже устарел) установлены процессоры Pentium Pro 200 МГц, 60-наносекундная память и жесткие диски со временем доступа 8,5 миллисекунд.

Да, за последние несколько лет разрыв в скорости между процессором и памятью-вводом/выводом вырос невероятно. Теперь вполне возможна ситуация, когда память и ввод-вывод не смогут поставлять достаточно информации для поддержания загрузки процессора, и последний будет проводить множество своих высокоскоростных циклов в ожидании выборки команд или данных.

Универсальный прием для компенсации разницы в производительности между процессором и основной памятью — применение кэшей. Как мы уже говорили, кэш — это быстродействующая память, используемая для хранения блоков команд и данных, к которым процессор недавно обращался. При этом предполагается, что в ближайшем будущем процессор будет обращаться к тем же самым блокам.

Кэши эффективны благодаря тому, что большинство программ обладают так называемыми пространственной и временной локализацией. Это означает, что программа, скорее всего, обратится к команде или элементу данных, расположенным в памяти недалеко от места последнего обращения (пространственная локализация); а также что такой доступ произойдет через короткий отрезок времени (временная локализация). Нетрудно предположить, некоторые программы обладают большей степенью локализации, чем другие. Программа, предполагающая выполнение многих циклов или большой объем повторной обработки одних и тех же данных, имеет очень высокую степень локализации. Приложения для коммерческих расчетов, наоборот, выполняют мало обработки такого сорта, и имеют несколько меньшую степень локализации. Большие кэши и иерархия кэшей могут обеспечить загрузку процессора данными и командами даже при низких уровнях локализации.

При использовании иерархии кэшей происходит следующее: если нужная процессору информация отсутствует в кэше L1, процессор обращается к кэшу L2. Если информация не найдена и там, то происходит обращение к основной памяти. Пока идет поиск информации и выборка ее в регистр, процессор простаивает. Обычно это называют циклами простоя (stall cycles) процессора. В том случае, если информации нет даже в основной памяти и система должна обратиться к диску, процессор не ждет, а переключается на выполнение другой задачи в системе. Такую ситуацию обычно называют страничной ошибкой (page fault). Подробней мы поговорим об этом в главе 8.

Высокая производительность Muskie достигается с помощью небольшого 8-кило-байтного кэша команд L1 и 256-килобайтного кэша данных L1. Большой кэш данных реализован на четырех отдельных 64-килобайтных микросхемах памяти высокого быстродействия. Будучи однокристальными процессорами, Cobra и Apache имеют гораздо меньшие внутренние кэши L1 (4К и 8К для команд и данных соответственно). Эти внутренние кэши дополняются кэшами L2 большего размера, выполненными в виде отдельных микросхем. Часть производительности Apache достигается за счет очень больших кэшей L2 объемом от 4 до 8 мегабайт.

Несмотря на использование больших кэшей и иерархии кэшей, большинство процессоров все равно тратят много циклов простоя, ожидая выборки из памяти. Проблема заключается в шине между процессором и основной памятью. Большая часть систем, включая ранние AS/400, имеют одну такую шину, обычно высокоскоростную, но все равно работающую медленнее самого процессора. Например, мой Intel Pentium Pro 200 МГц работает с шиной памяти 66 МГц. Это означает, что при обращении к памяти процессор простаивает по три цикла на каждый цикл шины. Легко понять, что таких циклов простоя может быть много.

В конфигурации SMP ситуация может значительно ухудшиться. Теперь одну шину памяти и одну основную память пытаются задействовать несколько процессоров. Так как в данный момент времени шина может использоваться только одним процессором, то все остальные процессоры, которым она понадобилась в этот момент, обречены ждать. А если та же шина памяти используется еще и для ввода-вывода, положение еще более усугубляется.

Эта борьба за шину памяти приводит к уменьшению производительности при добавлении к системе SMP каждого нового процессора. Например, добавление второго процессора не позволит увеличить общую производительность на 100 процентов; фактическое увеличение будет несколько меньшим из-за борьбы за память. Добавление третьего и четвертого процессора еще сильнее сократит прирост производительности на один процессор. А когда дело дойдет до восьми и более процессоров, рост производительности системы SMP может и вовсе прекратиться.

 

Организация памяти

Давайте проведем краткий обзор организаций памяти для многопроцессорных систем. Нас интересуют три схемы организации памяти: централизованная разделяемая память, распределенная память и распределенная разделяемая память.

Машина с централизованной разделяемой памятью предоставляет центральную память для использования всеми процессорами. Обычно, к такой разделяемой памяти подключены посредством одной шины несколько десятков процессоров. Подобная организация называется SMP (ее мы рассматривали выше). Преимущества SMP в том, что все процессоры используют общую память, и время необходимое для доступа к любой части этой памяти, для них одинаково. Поэтому конфигурации SMP часто называют машинами с однородным доступом к памяти UMA (uniform memory access). Недостаток SMP — в ограниченности максимально поддерживаемого числа процессоров.

В машинах с распределенной памятью последняя поделена между несколькими узлами, каждый из которых содержит несколько процессоров, соединенных с памятью узла как в SMP. Пример — кластер AS/400 OptiConnect (подробнее см. главу 6). Иногда машины с распределенной памятью называют архитектурами без разделения (shared-nothing), так как память не разделяется между узлами, а для связи между ними используется передача сообщений. Преимущество разделяемой памяти в том, что она может быть очень большой, если такое разделение памяти не требуется приложениям.

Если каждый процессор в машине с распределенной памятью может выполнять одну и ту же операцию или одну и ту же программу над множеством независимых друг от друга наборов данных, то подобная конфигурация называется процессором с массовым параллелизмом MPP (massively parallel processor). Пример — система MPP в IBM SP2, использующая по одному процессору на узел. У SP2 также очень хороший механизм передачи сообщений, позволяющий процессорам быстро обмениваться информацией друг с другом. Системы MPP могут насчитывать тысячи процессоров; их недостаток в том, что такая архитектура полезна только для некоторых типов приложений, таких как параллельная обработка баз данных или научных вычислений (то есть там, где совместное использование данных не требуется).

Третья конфигурация — с распределенной разделяемой памятью, представляет собой вариант распределенной памяти. Здесь все узлы, состоящие из одного или нескольких процессоров, подключенных по схеме SMP, используют общее адресное пространство. Отличие этой конфигурации от машины с распределенной памятью в том, что здесь любой процессор может обратиться к любому участку памяти. Однако, время обращения к разным участкам памяти для каждого процессора различно в зависимости от того, где участок физически расположен в кластере. По этой причине такие конфигурации еще называют машинами с неоднородным доступом к памяти NUMA (non-uniform memory access). Мы рассмотрим NUMA в главе 12.

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

 

Перекрестные переключатели

В рамках начавшейся в 1995 году десятилетней программы ASCI (Accelerated Strategic Computing Initiative) министерство энергетики США DOE (Department of Energy) запросило у производителей компьютеров предложения по созданию самых мощных на сегодня ЭВМ. Задача ACSI — разработка «триллионных» компьютеров, которые могут быть использованы в том числе для моделирования ядерных испытаний. Предполагается, что триллионные (tera-scale) вычисления (таково официальное название для триллиона операций в секунду) будут широко применяться в коммерческих и научных приложениях в следующем столетии. Такие компьютеры создаются в трех национальных лабораториях DOE, связанных с проектом ASCI.

На первом этапе проекта ASCI — ASCI Option Red — рассматривалась большая конфигурация MPP с процессорами, организованными по традиционной модели распределенной памяти. Intel получил контракт на разработку компьютера с 9 072 процессорами Pentium Pro, 283 гигабайтами памяти и двумя терабайтами дискового пространства. Эта система имеет архитектуру MPP без разделения. Испытания новой системы происходили в национальной лаборатории Сандиа (Sandia), штат Нью-Мехи-ко. Ставилась задача — Сандиа (Sandia), «выжать» из единственного в своем роде компьютера, стоимостью в 55 миллионов долларов, триллион операций с плавающей точкой в секунду (один терафлоп). В декабре 1996 компьютер Intel DOE достиг этой цели.

DOE также хотело устранить ограничения двух распространенных многопроцессорных архитектур (SMP и MPP). Как мы уже говорили, системы SMP использующие шины, не масштабируются больше 32 процессоров, но отлично работают для большинства приложений. Схемы MPP сложнее в программировании и подходят только для некоторых классов приложений. Кроме того, их работа сильно замедляется при необходимости доступа к данным, разбросанным по системе. Поэтому DOE предложила новый проект масштабируемого SMP, названного ASCI Option Blue.

Контракты на создание этих систем к концу 1998 года получили две компании, чьи предложения были самыми обещающими: IBM и Cray Research, которая была приобретена SGI (Silicon Graphics Incorporated). Машина IBM названная ASCI Blue Pacific будет установлена в национальной лаборатории имени. Лоуренса (Lawrence) в Ливер-море (Livermore), штат Калифорния, а машина SGI/Cray, получившая имя ASCI Blue Mountain — в национальной лаборатории в Лос-Аламосе (Los Alamos), штат Нью-Ме-хико. Задача обоих компьютеров Option Blue — достичь производительности более 3 терафлоп.

В проекте IBM используются компактные узлы SMP с восемью процессорами; эти узлы соединяются с помощью переключателей передачи сообщений SP2. Проект SGI/

Cray более сложен и включает в себя комбинацию соединений и технологий операционных систем с целью создания образа единой SMP-подобной машины. И хотя физически данные будут распределены по системе, это будет архитектура NUMA.

Компьютер IBM ASCI Blue Pacific будет содержать 512 8-процессорных узлов SMP, 4 096 сверхвысокопроизводительных процессоров PowerPC. Процессор, предназначенный для версии Belatrix Остина, назван 630. Он имеет высокую производительность для вычислений с плавающей точкой и в точности соответствует типу проблем, решать которые призван компьютер DOE.

Для связи между узлами в ASCI Blue Pacific планируется новый высокоскоростной переключатель передачи сообщений типа SP2. Подсистема памяти, позволяющая процессорам внутри узла эффективно использовать память, будет использовать новый 128-разрядный перекрестный переключатель (cross-bar switch). Подсистема памяти на основе таких переключателей позволяет нескольким процессорам обращаться к памяти узла параллельно и обеспечивает конфигурацию UMA, где устранена проблема, присущая шине памяти в большинстве конфигураций SMP.

Я упомянул о проекте DOE для того чтобы рассказать о новой подсистеме памяти, используемой в узлах SMP ASCI Blue Pacific. Первая подсистема UMA, использующая 128-разрядный перекрестный переключатель, была разработана в Рочестере. Аналогичная схема используется в настоящее время в компьютерах SMP Apache. Вместо одной шины между памятью и кэшем второго уровня, как в предыдущих системах SMP AS/400, в Apache применены перекрестные переключатели. Благодаря поддержке нескольких параллельных обращений к памяти за один цикл, возможна пересылка больших объемов данных между кэшем и разделяемой памятью, что позволяет поддерживать загрузку процессоров в больших конфигурациях SMP.

Пример подобной конфигурации с двенадцатью процессорами Вы можете увидеть на рисунке 2.6. На одной плате — четыре процессора Apache вместе с четырьмя кэшами L2. В 12-процессорной конфигурации установлено три таких платы. Размещенные на платах кэши L2 размером 4 или 8 мегабайт обладают цикличностью в 8 наносекунд. Таким образом, за один цикл процессора между кэшем второго уровня и кэшем данных или команд первого уровня в микросхеме Apache может быть передано 16 байтов (см. рисунок 2.5).

Основная память в данной конфигурации может достигать 20 гигабайт, каждая плата памяти — содержать до гигабайта, так что на рисунке 2.6 показаны 20 таких плат. Обратите внимание на наличие четырех банков памяти с одинаковым числом плат в каждом, что позволяет обеспечить прослоенную память (memory interleaving) — технический прием, при котором открывается доступ к последовательным блокам данных памяти через разные банки. Например, если каждая плата памяти имеет 8-байтовый интерфейс, то одновременно из четырех банков памяти может быть считано 32 последовательных байта (байты 0-7 из банка 1, байты 8-15 из банка 2 и т. д.).

Четыре перекрестных переключателя подсистемы памяти UMA обеспечивают соединение между кэшами второго уровня и платами основной памяти. Три шины данных 6хх — по одной на каждую плату процессора — соединяют 12 процессоров с каждым из четырех переключателей. Эти 128-разрядные шины данных имеют время цикла 12 наносекунд (в полтора раза больше времени цикла процессора). Дополнительная шина данных 6хх соединяет с каждым из переключателей памяти подсистему ввода-вывода. У каждого переключателя — два независимых 128-разрядных интерфейса к платам памяти.

В подобной конфигурации в каждом цикле памяти к ней может осуществляться несколько параллельных обращений, что фактически устраняет проблемы, связанные с использованием одной шины памяти на традиционных системах SMP.

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

Также, обратите внимание, что переключатели используются только линиями данных. Линии адресах всех кэшей второго уровня (показанные на рисунке как адресные линии 6хх) общие, что позволяет обычное отслеживание адресов, иначе называемое снупингом кэша (cache snooping) — прием, при котором каждый контроллер кэша L2 постоянно отслеживает все адреса, передаваемые по общей адресной шине. Кроме того, контроллеры проверяют, содержится ли адрес на шине в их кэше. Если это так, то соответствующие данные кэша становятся недействительными. Таким образом достигается когерентность информации во всех кэшах, ведь общие данные могут быть изменены одновременно не более чем одним процессором.

На рисунке 2.6 также показана общая подсистема ввода-вывода. Для подключения устройства расширения ввода-вывода к корпусу Mako, в котором размещается 12-процессорная конфигурация, используется SAN (System Area Network). Два таких интерфейса показаны на рисунке. В главе 10 мы рассмотрим использование SAN для поддержки разных интерфейсов ввода-вывода в AS/400е и соединения этих систем друг с другом.

Рисунок 2.6 12-конфигурация SMP

Итак, причина использования перекрестных переключателей — стремление повысить эффективность, или, иначе говоря, процентный рост производительности SMP при добавлении нового процессора в конфигурацию. Во многих системах с разделяемой памятью эта эффективность равна примерно 70 процентам при использовании от четырех до восьми процессоров. Благодаря новой подсистеме памяти, процессоры Apache должны поднять эффективность до 85—90 процентов.

 

Будущее переключателей памяти

Если используются иерархии кэшей, то почему бы не использовать иерархии переключателей? Фактически, именно это и произойдет в будущем. Мы рассмотрели пример, где каждый процессор был соединен посредством шины 6хх с каждым из четырех переключателей. А ведь вместо этого можно установить на каждый четырех процессорный узел один переключатель, который, логично назвать контроллером узла. Такие контроллеры могут быть подключены к набору переключателей, которые, в свою очередь, подключаются к банку плат памяти. Можно также подключить контроллеры узлов к нескольким наборам переключателей, а каждый из этих наборов — к отдельным банкам памяти. Таким образом будет получена очень большая конфигурация SMP. Вспомните этот разговор после выхода четвертого поколения процессоров Рочестера!

Вы еще не забыли про компьютер IBM ASCI Blue Pacific? В нем будет 512 процессорных узлов по восемь процессоров в каждом и подсистема памяти UMA на переключателях. Не следует ожидать в скором времени появления столь мощной версии AS/400, но разве не приятно осознавать, что такая конфигурация возможна, даже если и не очень практична? В конце концов, кодовым названием System/38 было Pacific, и мы действительно собирались создать по-настоящему большую систему. Ну что ж, посмотрим, как будут выглядеть рочестерские процессоры PowerPC следующего поколения...

 

Выводы

Сегодня 64-разрядный процессор стал стандартом в компьютерной промышленности. Все RISC-процессоры AS/400 — современные, 64-разрядные, способные обеспечить функциональные возможности и производительность, необходимую для коммерческих систем и серверов. Мы считаем, что семейство RISC-процессоров PowerPC приведет AS/400 в следующее столетие.

 

Глава 3

 

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

 

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

 

Неисполняемый интерфейс

Команды MI не исполняются аппаратурой непосредственно. Они либо предварительно (до исполнения программы) транслируются в аппаратный набор команд, либо специальный компонент SLIC интерпретирует некоторые команды MI одну за другой. Пример интерпретируемых команд MI — API Advanced 36. Мы называем процесс преобразования команд MI в низкоуровневые аппаратные команды трансляцией, а не компиляцией, так как при этом выполняется лишь часть функций компиляции. Прежде результатом такой трансляции был набор инструкций IMPI — теперь это набор инструкций PowerPC.

Набор инструкций MI нельзя считать ЯВУ в обычном смысле. Правильнее рассматривать его как разновидность промежуточного представления программы в современном компиляторе ЯВУ. Кое-кто предпочитает представлять набор инструкций MI как ЯВУ, требующий трансляции на более низкий уровень или исполнения посредством интерпретации. Краткое описание оптимизирующих компиляторов поможет понять, почему MI лучше рассматривать как промежуточное звено.

Структура современного оптимизирующего компилятора показана на рис. 4.1. Обычно, компилятор состоит из двух и более проходов или фаз. Проход — это одна фаза, за которую компилятор считывает и модифицирует всю программу. Термины фаза и проход часто используются как синонимы.

В процессе выполнения каждого прохода компилятор преобразуя программу, понижает уровень ее представления (от более абстрактного к менее). В конечном итоге получается набор команд аппаратуры. Такая структура оптимизирующего компилятора была впервые предложена в 60-х годах для упрощения сложных преобразований, имевших целью получение оптимизированного кода.

Возможности однопроходного компилятора по оптимизации ограничены. Проще говоря, он не может просмотреть код программы вперед и учесть то, что произойдет дальше. «Заглянуть вперед» может многопроходный компилятор. Назначение регистров переменным в зависимости от их связей с другими переменными, запись в память ненужного более содержимого кэша, предварительная выборка операндов — вот лишь некоторые примеры оптимизации, выполняемой многопроходным компилятором.

Оптимизации, произведенные компилятором, могут значительно ускорить выполнение программы, особенно если она работает на процессоре, способном выполнять несколько команд параллельно. RISC-процессор — именно такого типа и ему необходим оптимизирующий компилятор для достижения высокой производительности. Применение нескольких проходов также облегчает процесс написания самого компилятора.

Рисунок 4.1 Структура оптимизирующего компилятора

Первый проход компилятора, показанного на рис. 4.1, часто называют препроцессором (front end) компилятора. Его задача — преобразование текста на ЯВУ в общую промежуточную форму (common intermediate form).

Постпроцессор (back end) компилятора состоит из фаз оптимизации и фазы генерации кода. Препроцессоры зависят от ЯВУ, тогда как постпроцессоры — от аппаратуры. Если общая промежуточная форма независима как от ЯВУ, так и от аппаратуры, то она может использоваться несколькими компиляторами. Для каждого нового ЯВУ нужен лишь новый препроцессор. Аналогично, если создан постпроцессор для новой аппаратуры, то с ним будут работать все старые препроцессоры. Такой модульный подход упрощает создание компиляторов ЯВУ для нового компьютера.

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

Общая промежуточная форма для некоторых языков может как транслироваться, так и интерпретироваться. В главе 11 мы рассмотрим язык Java, использующий как раз такую форму. Промежуточная форма Java, известная как байт-код, также включена в MI.

Набор инструкций MI заменяет общую промежуточную форму не во всех компиляторах AS/400 — некоторые языки имеют собственную промежуточную форму. Ниже приводится описание внутренней структуры компиляторов языков для AS/400, и место MI в этой структуре.

 

Компиляторы для AS/400

Ранние компиляторы (например, RPG/400 и языка управления CL) для System/38 и AS/400 генерировали команды: MI довольно прямолинейно. Хотя они и проходили уровень ассемблера, в самом компиляторе не было общей промежуточной формы. Ее роль выполняли команды MI.

Модель программы для этих языков, включая форму программы ниже уровня MI, называется исходной моделью программ или OPM (Original Program Model). Позднее, для языков типа C/400, была добавлена расширенная модель программ или EPM (Extended Program Model). На рисунке 4.2 показан процесс генерации кода IMPI для OPM и ЕРМ. Мы представили здесь эти две модели только для демонстрации эволюции компиляторов AS/400. На RISC-системах версии 4 не используются ни компиляторы ОРМ, ни ЕРМ.

Сначала рассмотрим компилятор ОРМ. Он принимает на входе операторы ЯВУ ОРМ (вместе с не показанными на рисунке описаниями файлов) и на выходе генерирует код промежуточного представления программы IRP (Intermediate Representation of a Program). IRP, по сути, — ассемблер для команд MI. Следующий шаг — код IRP преобразуется в команды MI с помощью компонента под названием PRM (Program Resolution Monitor), который создает шаблон программы, помеченный на рисунке как шаблон программы ОРМ и содержащий команды MI и другие данные. Шаблоны используются для создания объектов MI. Транслятор, расположенный ниже уровня MI, создает по шаблону программы программный объект, содержащий команды IMPI. Содержание шаблона программы будет рассмотрено далее.

ОРМ — пример классического компилятора, генерирующего ассемблерную форму программы (IRP), после чего ассемблер (PRM) генерирует двоичную машинную программу (шаблон программы). Компиляция на AS/400 требует дополнительного шага (этапа трансляции) и поэтому может занимать больше времени, чем на некоторых других системах. Обратите внимание, что все эти этапы для пользователя AS/400 невидимы и выглядят, как одна операция.

По мере реализации на AS/400 новых языков, таких как С/400 и Pascal, потребовалось добавить расширения. Этапы компиляции для ЕРМ (расширенной версии ОРМ) также показаны на рис. 4.2. В компиляторах таких языков препроцессор и постпроцессор разделены. Общая промежуточная форма в них называется U-код. Для AS/400 был создан новый постпроцессор компиляторов CUBE-1 (Common Use Back End 1).