История развития семейства Intel x86 является лучшим подтверждением успехов современных технологий проектирования процессоров. Обоснованно критикуемая, обладающая рядом неоспоримых архитектурных недостатков x86 стала самой массовой, совершенствуемой и доступной. И при этом — далеко не худшей по показателям. Экстенсивное повышение производительности за счет увеличения тактовой частоты до нижней границы СВЧ-диапазона свидетельствует об исключительно удачной топологии современных x86 и высочайшем качестве схем синхронизации — как ни странно, но в перечне целей разработчиков канонических RISC-процессоров эти задачи занимали первые места. В подтверждение всему вышесказанному — до сих пор, увы, ни один из декларируемых каноническими RISC-процессоров не "взял" гигагерцевой планки.
Но "сколь веревочке не виться", переход на качественно новый уровень неизбежен. Пользователи компьютеров ненасытны — их аппетиты растут в точном соответствии с партитурой Листа: "Быстро. Еще быстрее. Быстро как только возможно". И, похоже, что даже работающие на частотах радиолокационных станций 32-битовые процессоры ограничены верхними уровнями требования "…Еще быстрее…". Для огромного класса задач этой производительности более чем достаточно, но коммерчески успешное применение программных технологий из специализированных секторов ПО (в первую очередь — CAD и визуализации данных) в обычных "настольных" и развлекательных приложениях вносит существенные коррективы в планы "расширения разрядности". А именно, если еще недавно от будущих 64-битовых последователей x86 не ожидали никаких потрясений на массовом рынке ПК (даже высокого уровня) и подчеркивали нацеленность этих процессоров исключительно на применение в серверном секторе, то после обнародования компанией AMD спецификаций на архитектуру x86-64 все полностью меняется.
В "генеральном сражении" ближайшего времени на карту будут поставлены не только (и даже не столько) преимущество на рынке серверов, но и "полная, окончательная победа" в войне за "десктоп".
История и Дональд Кнут
Как это ни странно может звучать, но автор великих книг, без тени сомнения заслуживающих титула "Компьютерной Библии" (речь, естественно, идет об "Искусстве программирования"), в контексте описания "реинкарнации" архитектуры x86 может оказать весьма ощутимую помощь. В ожидающейся со дня на день новой редакции "Искусства программирования" реализации всех алгоритмов будут иллюстрироваться программами для новой "самой виртуальной" машины под названием MMIX 2009. Как и архитектура MIX, использовавшаяся в прежних изданиях, MMIX представляет собой квинтэссенцию всего лучшего, что есть в мире CPU в настоящее время, и, естественно, отражает скрытые тенденции в развитии процессорных архитектур. Сам Д. Кнут в присущей ему ироничной манере так характеризует название нового "процессора": "…номер 2009 был найден на основе имен 14 существующих компьютеров, очень похожих на MMIX, на которых MMIX может быть легко имитирован". Полный перечень имен этих "основоположников" состоит исключительно из канонических (или объявленных их производителями каноническими) RISC-машин: Cray I, IBM 801, RISC 801, Clipper C300, AMD 29K, Motorola 88K, IBM601, Intel i960, Alpha 21164, POWER 2, MIPS R4000, Hitachi SuperH4, StrongARM110, SPARC64.
Судьба у этих процессоров и компьютеров разная — некоторые из них уже стали прошлым (AMD 29K, например), некоторые мигрировали из класса "мощных RISC-процессоров для универсальных компьютеров" в класс "встраиваемых устройств" (R4000, SuperH, i960), два заняли прочные позиции "высокопроизводительных CPU для мощных рабочих станций и серверов" (Alpha и SPARC). Наконец, одному из них (StrongARM) еще предстоит сказать свое слово.
Д. Кнут проделал немалую работу по формированию абстракции, объединяющей в себе лучшие черты всех этих машин. В результате MMIX 2009, с точки зрения программиста (согласитесь, это самый важный персонаж — ведь сколь бы ни был хорош процессор "сам по себе", без программ его полезность равна нулю), выглядит весьма просто — он содержит 256 64-битовых регистров общего назначения и 32 специальных регистра той же разрядности. Система команд MMIX весьма проста, она содержит 256 инструкций, большинство из которых — трехоперандные (например, команду ADD $R5,$R124,$R63 на "человеческом" языке можно передать фразой "записать в регистр R5 результат сложения содержимого регистров R124 и R63).
Более подробно знакомиться с MMIX нам не понадобится (в конце концов, новое издание "Искусства программирования" совсем скоро появится и у нас, а самые нетерпеливые могут загрузить с сайта Д. Кнута небольшой файл с описанием MMIX). Зато общие характеристики этого "абстрактного процессора" и особенности его названия еще пригодятся.
В реальном мире x86, увы, архитектуры не блещут красотой и простотой MMIX. Родоначальник всего семейства, ставший уже раритетом процессор i8080, содержал семь 8-битовых регистров общего назначения A, B, C, D, E, H, L (шесть из них в некоторых 16-битовых командах использовались как регистровые пары BC, DE, HL), указатель стека (SP) и счетчик команд (PC). Следует отметить, что i8080 представлял собой дополненный аппаратной реализацией стека первый 8-битовый процессор Intel — i8008. На следующем шаге — i8086/i8088, с которых началось победное шествие IBM PC, девять 8-битовых регистров i8080 трансформировались в тринадцать 16-битовых (имена некоторых из них стоит привести без дополнительных комментариев — в дальнейшем они еще не раз встретятся: AX, BX, CX, DX, SP, BP, SI, DI). После i8086 началась "эпоха x86" — в обозначениях процессоров появилась дополнительная цифра. "Первенец" x86 — i80186 в мире ПК не прижился, его последователь i80286 также быстро ушел со сцены. Зато третий в поколении "шестой ребенок" (с учетом i8008) i80386 стал праотцом практически всего, что сегодня емко называется "ПК IBM PC-архитектуры". Следующие поколения (486, 586, условно — 686) фактически не коснулись "святая святых" — базового регистрового набора и базовой системы команд, что обеспечивает бинарную совместимость "снизу вверх". И вот, наконец, финал — Intel решилась отвергнуть бинарную совместимость в пользу роста производительности. Все еще ожидаемые IA64 (Merced) — это уже процессоры из совсем другого мира.
"Бархатная революция"
В отличие от своих коллег из Intel конструкторы AMD не решились на "настоящую революцию". Несмотря на это будущий 64-битовый процессор AMD на фоне последних событий выглядит очень перспективно, а подход самой компании AMD можно назвать "осторожно-продуманным".
Эти неочевидные, на первый взгляд, утверждения можно достаточно обоснованно мотивировать, следует только вспомнить недавнюю историю процессоров компании Transmeta. У будущей IA64 и уже существующих чипов от Transmeta действительно очень много общего — обе архитектуры основаны на идеях VLIW (процессоры с "очень большой" разрядностью команды) и RISC (в части фиксации длины "подкоманды"). VLIW позволяет за одно обращение к памяти получить "упакованные" в одно метакомандное слово несколько RISC-"подкоманд" фиксированной длины (в Intel не любят эти "подкоманды" называть RISC-подобными и придерживаются иной терминологии — EPIC, Explicitly Parallel Instruction Computing), которые можно эффективно выполнить за один такт "в параллель". Идея, без сомнения, красивая и, на первый взгляд, обеспечивающая очень высокую производительность. Однако и у нее есть свои изъяны.
Так, если от подобных "параллельных микровычислителей" потребуется имитация набора команд другого процессора, то следует ждать неприятностей. И совершенно безразлично, с помощью какой высокоуровневой технологии будет осуществляться трансформация чуждой системы команд в наборы EPIC/RISC "подкоманд" — статической или динамической компиляции. Важно другое — деградации производительности по сравнению с "родной" платформой не избежать. По крайней мере, неудача (мягко говоря) Crusoe — VLIW-процессора от Transmeta полностью подтверждает это опасение. Кроме того, сложность высокоуровневых программных технологий, с помощью которых осуществляется трансформация одной системы команд в другую, очень высока. Речь идет не столько о сложности реализации, сколько о слабой изученности теоретических предпосылок и необходимости применения методов оптимизации для параллельных вычислений. Полные пессимисты утверждают, что пока не существует математического аппарата, с помощью которого можно доказать оптимальность трансформации хотя бы фрагмента кода, очень дорогостоящее и сложное аппаратное обеспечение VLIW-систем будет использоваться неоптимально.
Оптимисты, в свою очередь, утверждают, что все рассуждения о недостатках VLIW лишены оснований по причине абсолютно неправильно выбранной отправной точки. А именно, необходимости в исполнении бинарных приложений, транслированных в "неродную" систему команд. С этой точки зрения все современные приложения (включая системное ПО) написаны на языках программирования высокого уровня, и для переноса их на другую платформу необходимы только соответствующие инструментальные средства. Обе точки зрения во многом правильны, но… существует еще и суровая реальность. Современное программное обеспечение действительно разрабатывается на языках программирования высокого уровня, но насколько этот уровень высок? Самые популярные на сегодняшний день языки C и C++, например, при традиционном подходе к разработке фактически не позволяют описывать платформенно-независимые встроенные типы данных (хотя бы целые числа). В реальных (т. е. достаточно больших) программных проектах это может означать, что для переноса методом перекомпиляции ПО с 32-битовой аппаратной платформы на 64-битовую могут возникать (и в действительности возникают) чуть ли не непреодолимые проблемы. Ситуация обостряется и за счет постоянно используемых "трюковых" приемов при прикладном программировании, которыми грешат даже очень крупные проекты: когда разработчик стремится к коммерческому успеху своей программной системы, он добивается, например, высокой производительности за счет аппаратно-программных особенностей конкретных компьютеров текущего поколения. Ругать программные компании за это нельзя — "трюковое" программирование является просто следствием упомянутого в начале статьи непомерного роста "аппетита". Ну и, наконец, системное программирование вообще невозможно без машинно-зависимых деталей реализации. Даже если учесть эти три фактора, трудно слишком оптимистично утверждать, что для миграции на новые VLIW-платформы достаточно только процесса перекомпиляции в новую систему команд.
Теперь пора кратко охарактеризовать "бархатно-революционную" архитектуру AMD x86-64. Во-первых, это 64-битовая архитектура. Во-вторых, она же еще и 32-битовая. В-третьих, она же — 16-битовая. В-четвертых, 32- и 16-битовые архитектуры полностью идентичны классическим x86. В-пятых, идентичность здесь подразумевает способность аппаратно выполнять программы для всех архитектур без всякой трансформации кода, динамической компиляции и прочих VLIW-ухищрений. В-шестых, самая мощная, 64-битовая, архитектура достаточно традиционна и не требует излишних сложностей реализации компиляторов с традиционных же языков программирования. В-седьмых, разработчиками предусмотрен режим работы новых процессоров, который можно назвать "мирным сосуществованием архитектур": так, под управлением 64-битовой операционной системы могут без перекомпиляции выполняться бинарные приложения для 32-битовой (или 16-битовой) x86.
После такой положительной характеристики, несомненно, следует вспомнить прозвучавшее в начале статьи утверждение о смещении области интересов будущих производителей 64-битовых процессоров в сторону настольных систем. Мы уже располагаем минимальным перечнем сведений, позволяющих это утверждение обосновать. Элементарная логика подсказывает, что число серверных приложений действительно намного меньше по сравнению с "настольными", и вследствие их происхождения из мира "mission-critical" (которому свойственна более высокая культура проектирования ПО) они не слишком сильно зависят от платформы. Так что производителей серверного ПО не пугает необходимость перекомпиляции. Но и не прельщает перспектива потери производительности из-за VLIW-эмуляции системы команд. С другой стороны, разработчики больших "настольных" программных систем действительно не заинтересованы "ударными темпами" переносить свои программы на VLIW (как уже говорилось, в некоторых случаях это может быть просто неосуществимо). Получается, что архитектура x86-64 на самом деле больше ориентирована на высокопроизводительные рабочие станции, чем на серверы. И в этом случае AMD получает "дополнительные баллы" — уже совершенно не важно, будет ли IA64 "мощнее" x86-64 при работе в "родных" системах команд или нет. По крайней мере, на колоссальном множестве уже существующих и неплохих приложений x86-64 точно будет дешевле и, вероятнее всего, производительнее. А что самое главное, — привлекательнее для разработчиков прикладных и системных программ.
"Кувалда"
Несмотря на то что в распространяемой самой компанией AMD предварительной документации на x86-64 подчеркивается, что будущие процессоры этой архитектуры являются "расширением 32-битовой x86", Hammer (лучший русский эквивалент — "кувалда") представляет собой очень похожий на… MMIX-процессор. Правда, регистров общего назначения у него не 256 (вероятнее всего, что 64-битовые числодробилки с таким количеством регистров появятся значительно позже, приблизительно в 2009 г., в полном соответствии с шутливым названием Д. Кнута), а "всего лишь" шестнадцать. И в отличие от MMIX эти регистры могут использоваться только в целочисленных операциях. Для операций с плавающей точкой (и для совместимости с x86) предусмотрены еще восемь 64-битовых регистров. Дополняют картину устрашающей мощи "кувалды" шестнадцать 128-битовых регистров, предназначенных для хранения операндов команд SIMD-расширения (Single Instruction Multiple Data — группа данных, обрабатываемых одной командой). Описание архитектуры предусматривает 64-битовую адресацию линейного виртуального адресного пространства, приблизительно в 4 млрд. раз большего, чем у 32-битовых процессоров.
"А где же совместимость с x86?" — спросите вы. Действительно, такая интерпретация описания x86-64 как бы подчеркивает, что на регистровом уровне ничего общего у классических x86 и "кувалды" нет. Но не все так просто. Регистры общего назначения R0-R7 в x86-64 "прячут" в своих младших битах… полные эквиваленты классического регистрового набора 80×86. Так, битовое поле 0…7 регистра R0 фактически эквивалентно регистру A (аккумулятору) ушедшего в прошлое процессора i8080 и регистру AL i8086. Соответственно битовое поле 8…15 регистра R0 является эквивалентом регистра AH i8086 (и "теневого" программно-недоступного второго аккумулятора i8080). Объединение этих двух полей — точный эквивалент регистра AX i8086. Ну и, наконец, битовое поле 0…31 того же R0 "кувалды" — полный эквивалент регистра EAX 32-битовых 80×86. Для более подчеркнутой x86-совместимости первые восемь регистров "кувалды" даже обозначаются не принятыми в подобных случаях мнемониками (R0…R7), а названиями, отражающими x86-происхождение: RAX, RBX, RCX, RDX, RSP, RBP, RSI, RDI. Каждый из них содержит в битовых полях 0…7, 8…15, 0…15, 0…31 полную историю всех поколений архитектуры x86.
Но регистровая совместимость — это еще не все. Естественно, что разработчики "кувалды" воспользовались самым очевидным и беспроигрышным приемом — они реализовали систему команд x86, использующую битовые поля RAX-RDI в качестве "родных" x86 регистров, и распространили действие почти всех команд на 64-битовые регистры. Прием этот замечателен тем, что сохранение, скажем так, концептуальной модели x86 на 64-битовом уровне позволяет очень быстро разработать компиляторы с языков высокого уровня — многие приемы генерации кода, отработанные на 80×86, применимы и для x86-64.
И наконец, о главном — в работе "кувалды" предусматривается так называемый "большой совместимый режим" (long/compatibility mode), при котором под управлением 64-битовой операционной системы можно, например, запускать исполняемые файлы x86 без всякой перекомпиляции.
Субъективное
Если во всем предыдущем материале автор старательно избегал высказывания собственных соображений по поводу перспективности и применимости x86-64 и пытался тщательно мотивировать каждое кажущееся спорным утверждение, то настало время для вещей субъективных.
Hammer действительно хорош. С точки зрения разработчиков системного ПО, наследование архитектурных особенностей x86 означает легкость применения "обкатанных" на "классических" 80×86 решений. С точки зрения разработчиков прикладного ПО, этот процессор позволяет в период "буферных продаж" уже отработанных 32-битовых программ спокойно и без гонки перейти на перспективные 64 бита. С точки зрения разработчиков персональных компьютеров, только два предыдущих соображения выводят "кувалду" в фавориты. И наконец, с точки зрения пользователей (с учетом предыдущих точек зрения), Hammer также выглядит исключительно выгодным приобретением. Единственное "но", способное разрушить всю эту идиллическую картину, — производственные возможности AMD: 64-битовый "монстр" — это не игрушка.
Если же попытаться совсем абстрагироваться от приземленных проблем, то "кувалда" исключительно хороша тем, что x86-64 — это уже не совсем x86 (или даже совсем не x86). А значит, следует ожидать и роста интереса к новым операционным системам, хорошо соответствующим возможностям процессоров с большой разрядностью (так называемые ОС с единым адресным пространством — single address space), и расширения возможностей уже хорошо зарекомендовавших себя ОС.