801 был экспериментальным проектом центрального процессора (ЦП) , разработанным IBM в 1970-х годах. Он считается первым современным проектом RISC , полагающимся на регистры процессора для всех вычислений и устраняющим множество вариантов адресации, обнаруженных в проектах CISC . Первоначально разработанный как процессор для телефонного коммутатора , он позже использовался в качестве основы для мини-компьютера и ряда продуктов для их линейки мэйнфреймов . Первоначальный проект представлял собой 24-битный процессор; вскоре он был заменен 32-битными реализациями тех же концепций, а оригинальный 24-битный 801 использовался только в начале 1980-х годов.
801 оказал огромное влияние на компьютерный рынок. [ необходима цитата ] Вооружившись огромными объемами данных о производительности, IBM смогла продемонстрировать, что простая конструкция способна легко превзойти даже самые мощные классические конструкции ЦП, в то же время производя машинный код , который был лишь незначительно больше, чем сильно оптимизированные инструкции CISC. Применение этих же методов даже к существующим процессорам, таким как System/370 , как правило, удваивало производительность этих систем. Это продемонстрировало ценность концепции RISC, и все будущие системы IBM были основаны на принципах, разработанных в ходе проекта 801.
За свою работу над моделью 801 Джон Кок был отмечен несколькими наградами и медалями, включая премию Тьюринга в 1987 году, Национальную медаль в области технологий в 1991 году и Национальную медаль в области науки в 1994 году.
В 1974 году IBM начала изучать возможность создания телефонного коммутатора , способного обрабатывать миллион звонков в час, или около 300 звонков в секунду. Они подсчитали, что для каждого звонка потребуется 20 000 инструкций, а если учесть временные затраты и другие соображения, то производительность такой машины должна составлять около 12 MIPS. [1] Это потребовало бы значительного повышения производительности; их текущая топовая машина, IBM System/370 Model 168 конца 1972 года, предлагала около 3 MIPS. [2]
Группа, работающая над этим проектом в исследовательском центре Томаса Дж. Уотсона , включая Джона Кока , разработала процессор для этой цели. Чтобы достичь требуемой производительности, они рассмотрели тип операций, требуемых такой машиной, и удалили все, что было неподходящим. Это привело к удалению, например, блока с плавающей точкой , который не был бы нужен в этом приложении. Что еще более важно, они также удалили многие из инструкций, которые работали с данными в основной памяти , и оставили только те инструкции, которые работали с внутренними регистрами процессора , поскольку они были намного быстрее в использовании, и простой код в телефонном коммутаторе мог быть написан для использования только этих типов инструкций. Результатом этой работы стал концептуальный проект для упрощенного процессора с требуемой производительностью. [1]
Проект телефонного коммутатора был отменен в 1975 году, но команда достигла значительного прогресса в концепции, и в октябре IBM решила продолжить его как проект общего назначения. Не имея очевидного проекта, к которому можно было бы его привязать, команда решила назвать его «801» в честь здания, в котором они работали. Для роли общего назначения команда начала рассматривать реальные программы, которые будут запускаться на типичном мини-компьютере . IBM собрала огромное количество статистических данных о производительности реальных рабочих нагрузок на своих машинах, и эти данные показали, что более половины времени в типичной программе тратилось на выполнение всего пяти инструкций: загрузка значения из памяти, сохранение значения в памяти, переход, сравнение чисел с фиксированной точкой и сложение чисел с фиксированной точкой. Это предполагало, что та же самая упрощенная конструкция процессора будет работать так же хорошо для мини-компьютера общего назначения, как и для коммутатора специального назначения. [3]
Этот вывод противоречил современному дизайну процессоров, основанному на концепции использования микрокода . IBM была одной из первых, кто широко использовал эту технику в своей серии System/360 . Модели 360 и 370 выпускались с различными уровнями производительности, которые работали на одном и том же машинном языке . На высокопроизводительных машинах многие из этих инструкций были реализованы непосредственно в оборудовании, например, в блоке с плавающей точкой, в то время как низкопроизводительные машины могли вместо этого имитировать эти инструкции, используя последовательность других инструкций, закодированных в микрокоде. Это позволяло единому двоичному интерфейсу приложения работать во всей линейке и позволяло клиентам быть уверенными, что если когда-либо понадобится большая производительность, они смогут перейти на более быструю машину без каких-либо других изменений. [4]
Микрокод позволял простому процессору предлагать множество инструкций, которые использовались разработчиками для реализации широкого спектра режимов адресации . Например, инструкция типа ADDмогла иметь дюжину версий, одна из которых добавляла два числа во внутренние регистры, другая добавляла регистр к значению в памяти, третья добавляла два значения из памяти и т. д. Это позволяло программисту выбирать именно ту вариацию, которая была нужна для любой конкретной задачи. Процессор считывал эту инструкцию и использовал микрокод, чтобы разбить ее на ряд внутренних инструкций. Например, добавление двух чисел в память можно было реализовать путем загрузки этих двух чисел в регистры, их сложения и последующего сохранения суммы обратно в памяти. [3] Идея предложения всех возможных режимов адресации для всех инструкций стала целью разработчиков процессоров, и эта концепция стала известна как набор ортогональных инструкций .
Команда 801 заметила побочный эффект этой концепции: столкнувшись с множеством возможных версий данной инструкции, авторы компиляторов обычно выбирали одну версию. Обычно это была та, которая была реализована в оборудовании на младших машинах. Это гарантировало, что машинный код, сгенерированный компилятором, будет работать максимально быстро на всей линейке. В то время как использование других версий инструкций могло работать еще быстрее на машине, которая реализовала их в оборудовании, сложность определения того, какую из них выбрать в постоянно меняющемся списке машин, делала это крайне непривлекательным, и авторы компиляторов в значительной степени игнорировали эти возможности. [3]
В результате большинство инструкций, доступных в наборе инструкций, никогда не использовались в скомпилированных программах. И именно здесь команда сделала ключевую реализацию проекта 801:
Навязывание микрокода компьютеру и его пользователям влечет за собой дорогостоящие накладные расходы при выполнении наиболее часто выполняемых инструкций. [3]
Микрокоду требуется ненулевое время для проверки инструкции перед ее выполнением. Тот же базовый процессор с удаленным микрокодом устранил бы эти накладные расходы и выполнил бы эти инструкции быстрее. Поскольку микрокод по сути выполнял небольшие подпрограммы, предназначенные для конкретной аппаратной реализации, он в конечном итоге выполнял ту же базовую задачу, что и компилятор, реализуя инструкции более высокого уровня как последовательность машинно-специфичных инструкций. Простое удаление микрокода и реализация его в компиляторе могли бы привести к более быстрой машине. [3]
Одной из проблем было то, что программы, написанные для такой машины, будут занимать больше памяти; некоторые задачи, которые можно было выполнить с помощью одной инструкции на 370, пришлось бы выразить в виде нескольких инструкций на 801. Например, сложение двух чисел из памяти потребовало бы двух инструкций загрузки в регистр, добавления регистра в регистр, а затем сохранения в памяти. Это могло бы потенциально замедлить работу системы в целом, если бы ей пришлось тратить больше времени на чтение инструкций из памяти, чем раньше на их декодирование. По мере того, как они продолжали работать над проектом и улучшали свои компиляторы, они обнаружили, что общая длина программы продолжала уменьшаться, в конечном итоге став примерно такой же длины, как у написанных для 370. [5]
Первоначально предложенная архитектура представляла собой машину с шестнадцатью 24-битными регистрами и без виртуальной памяти . [6] [7] Она использовала формат с двумя операндами в инструкции, так что инструкции, как правило, имели форму A = A + B, в отличие от формата с тремя операндами, A = B + C. Полученный ЦП был готов к работе к лету 1980 года и был реализован с использованием технологии дискретных компонентов Motorola MECL-10K [8] на больших платах с накруткой проводов. ЦП работал на тактовой частоте 66 нс (приблизительно 15,15 МГц) и мог выполнять вычисления с высокой скоростью около 15 MIPS .
Архитектура 801 использовалась в различных устройствах IBM, включая контроллеры каналов для их мэйнфреймов S/370 (таких как IBM 3090 ), [9] : 377 различных сетевых устройств, а также в качестве вертикального блока выполнения микрокода в процессорах 9373 и 9375 семейства мэйнфреймов IBM 9370. [10] [11] Первоначальная версия архитектуры 801 была основой для архитектуры микропроцессора IBM ROMP [9] : 378, используемого в компьютере рабочей станции IBM RT PC и нескольких экспериментальных компьютерах от IBM Research . Производная от архитектуры 801 с 32-битной адресацией под названием Iliad была предназначена для использования в качестве основного процессора неудачного проекта системы среднего уровня Fort Knox . [12]
Первоначально разработанная для системы с ограниченной функциональностью, конструкция 801 не имела ряда функций, которые можно было увидеть на более крупных машинах. Среди них следует отметить отсутствие аппаратной поддержки виртуальной памяти , которая не была нужна для роли контроллера и была реализована в программном обеспечении на ранних системах 801, которым она была нужна. Для более широкого использования аппаратная поддержка была обязательной функцией. Кроме того, к 1980-м годам компьютерный мир в целом переходил на 32-битные системы, и возникло желание сделать то же самое с 801. [13]
Переход к 32-битному формату имел еще одно существенное преимущество. На практике было обнаружено, что формат с двумя операндами было трудно использовать в типичном математическом коде. В идеале оба входных операнда оставались бы в регистрах, где их можно было бы повторно использовать в последующих операциях. В формате с двумя операндами одно из двух значений перезаписывалось результатом, и часто случалось так, что одно из значений приходилось повторно загружать из памяти. При переходе к 32-битному формату дополнительные биты в словах инструкций позволяли указать дополнительный регистр, так что вывод таких операций можно было направить в отдельный регистр. Большее слово инструкций также позволяло увеличить количество регистров с шестнадцати до тридцати двух, изменение, которое было очевидно из изучения кода 801. Несмотря на расширение слов инструкций с 24 до 32 бит, программы не выросли на соответствующие 33% из-за избегания загрузок и сохранений из-за этих двух изменений. [13]
Другие желательные дополнения включают инструкции для работы со строковыми данными, которые были закодированы в «упакованном» формате с несколькими символами в одном слове памяти, и дополнения для работы с двоично-десятичными числами , включая сумматор, который мог переносить четырехбитные десятичные числа. [13]
Когда новая версия 801 была запущена в качестве симулятора на 370, команда с удивлением обнаружила, что код, скомпилированный для 801 и запущенный в симуляторе, часто работал быстрее, чем тот же исходный код , скомпилированный непосредственно в машинный код 370 с использованием компилятора PL/I 370. [14] Когда они портировали свой экспериментальный язык "PL.8" обратно на 370 и скомпилировали приложения с его помощью, эти приложения работали в три раза быстрее, чем версии PL/I. Это было связано с тем, что компилятор принимал решения, подобные RISC, о том, как сгенерированный код использует регистры процессора, тем самым оптимизируя как можно больше обращений к памяти. Они были такими же дорогими на 370, как и на 801, но эта стоимость обычно скрывалась простотой одной строки кода CISC. Компилятор PL.8 был гораздо более агрессивен в избегании загрузок и сохранений, тем самым обеспечивая более высокую производительность даже на процессоре CISC. [14]
В начале 1980-х годов уроки, полученные на 801, были объединены с уроками из проекта IBM Advanced Computer Systems , что привело к появлению экспериментального процессора под названием «Cheetah». Cheetah был 2-процессорным суперскалярным процессором , который в 1985 году превратился в процессор под названием «Panther», а в 1986 году — в 4-процессорную суперскалярную конструкцию под названием «America». [15] Это был набор из трех чипов процессора, включающий процессор инструкций, который извлекает и декодирует инструкции, процессор с фиксированной точкой, который разделяет обязанности с процессором инструкций, и процессор с плавающей точкой для тех систем, которые в этом нуждаются. Разработанный командой 801, окончательный проект был отправлен в офис IBM в Остине в 1986 году, где он был преобразован в систему IBM RS/6000 . RS/6000, работающая на частоте 25 МГц, была одной из самых быстрых машин своей эпохи. Он превзошел другие RISC-машины в два-три раза на обычных тестах и легко превзошел старые CISC-системы. [10]
После RS/6000 компания обратила внимание на версию концепций 801, которую можно было бы эффективно изготовить в различных масштабах. Результатом стала архитектура набора инструкций IBM POWER и ответвление PowerPC .
За работу над моделью 801 Джон Кок был награжден несколькими наградами и медалями:
Майкл Дж. Флинн рассматривает 801 как первый RISC-компьютер. [22]