Аргументы в поддержку компьютера RISC с упрощенным набором инструкций
Девид Патерсон — Университет Калифорнии, Беркли
Девид Дитзел — Белл лабораториз, Нью Джерси
Перевод Бабкин И., ЛГТУ.
Введение
Одна из основных задач архитекторов компьютерных систем заключается в разработке компьютеров, которые являются более экономически эффективными, чем их предшественники. Экономическая эффективность включает в себя стоимость оборудования для производства машины, стоимость программирования, а также расходы, связанные с архитектурой через отладку как сначала аппаратного, так и затем программного обеспечения. Если мы рассмотрим историю компьютерных архитектур, то увидим, что наиболее распространенным архитектурным изменением является тенденция к построению все более сложных компьютеров. Предположительно, это дополнительная сложность имеет положительный компромисс в отношении экономической эффективности новых моделей. В данной работе мы предполагаем, что эта тенденция не всегда является экономически эффективной, а на самом деле, возможно, даже приносит больше вреда, чем пользы. Рассмотрим пример компьютера с упрощенным набором команд (RISC), являющимся таким же рентабельным, как и компьютер со сложным набором команд (CISC). В этой статье мы утверждаем, что следующее поколение компьютеров на СБИС может быть более эффективно реализовано в виде RISC, чем CISC.
В качестве примеров такого увеличения сложности, рассмотрим переходы от IBM System/3 к IBM System/38 [1] и от DEC PDP-11 к VAX II. Сложность определяется размером ПЗУ микропрограмм: для DEC размер вырос с 256×56 в PDP 11/40 до 5120×96 в VAX 11/780.
Причины увеличивающейся сложности
Почему компьютеры стали более сложными? Мы можем назвать несколько причин:
Скорость памяти по отношению к скорости процессора. Джон Кок утверждает, что усложнение началось с переходом от IBM 701 к IBM 709 [2]. ЦП 701 был примерно в десять раз быстрее, чем оперативная память — это сделало любые примитивы, реализованные в виде подпрограмм гораздо медленнее, чем примитивы, представленные инструкциями. Таким образом, подпрограммы работы с плавающей точкой стали частью архитектуры с ЦП 709. То, что 709 стал более сложным, привело к улучшению архитектуры и сделало его более рентабельным, чем 701. С тех пор многие инструкции «более высокого уровня» были добавлены к компьютерам в попытке улучшить их производительность. Обратите внимание, что эта тенденция началась из-за дисбаланса в скорости: неизвестно, спрашивали ли себя архитекторы, содержат ли их проекты этот дисбаланс до сих пор.
Микрокод и БИС. Микропрограммы позволяют реализовать сложные архитектуры более рентабельно, чем жестко заданные схемы управления [3]. Достижения в области интегральных схем памяти, сделанные в конце 60-х и начале 70-х годов привели к тому, что применение микропрограмм стало более экономически эффективным подходом в во всех случаях. После того, как принимается решение об использовании микропрограмм, затраты на расширение набора инструкций становятся очень малыми: всего лишь несколько слов ПЗУ микропрограмм. Поскольку размеры ПЗУ микропрограмм часто бывают кратны степеням двойки, иногда набор инструкций может быть усложнен без каких-либо дополнительных затрат за счет расширения микропрограммы, чтобы полностью заполнить ПЗУ. Таким образом, достижения в микроэлектронике привели к экономически эффективной реализации архитектур, которые внедрили традиционные подпрограммы в архитектуру. Примерами таких инструкций являются редактирование строк, преобразование целого числа к числу с плавающей точкой и некоторые математические операции, например полиномиальные вычисления.
Плотность кода. В первых компьютерах, память была очень дорогой. Поэтому было экономически выгодно иметь очень компактные программы. Сложные наборы инструкций часто предвещали за их «возможное» уплотнение кода. Попытка увеличить плотность кода за счет увеличения сложности набора инструкций -- часто палка о двух концах, однако, чем больше инструкций и режимов адресации, тем больше требуется битов для их представления. Имеющиеся данные свидетельствуют о том, что уплотнение кода может быть легко достигнуто лишь путем очистки первоначального набора инструкций. Уплотнение кода важно, однако стоимость увеличения памяти на 10% зачастую намного дешевле, чем выжимание 10% из процессора с помощью архитектурных "инноваций". Затраты на большой процессор связаны с дополнительными наборами схем, в то время как стоимость одночипового процессора, скорее всего, будет связана с замедлением производительности из-за более крупных (следовательно, более медленных) управляющих логических схем (PLA). Cost for a large scale cpu is in additional circuit packages needed while cost for a single chip cpu is more likely to be in slowing down performance due to larger (hence slower) control PLA's.
Маркетинговая стратегия. К сожалению, основной задачей компьютерной компании является не проектирование наиболее экономически эффективного компьютера, а получение большего количества прибыли от продажи компьютеров. Для того, чтобы продавать компьютеры, производители должны убедить клиентов, что их архитектура лучше, чем у конкурентов. Сложные наборы инструкций, безусловно, являются основным «маркетинговым» свидетельством лучшего компьютера. Для того, чтобы сохранить свои рабочие места, разработчики должны продолжать продавать новые и лучшие проекты. Количество инструкций и их «мощность» часто используются для продвижения, несмотря на реальное использование или эффективность сложного набора инструкций. В каком-то смысле, производители и разработчики не могут быть обвинены в этом до тех пор, пока покупатели компьютеров не ставят под сомнение вопрос о сложности в сравнении с эффективностью. Для полупроводниковых производств, модные .. поскольку они получает большую прибыль если заставят клиентов покупать большие объемы памяти для их относительно недорогого процессора. For the case of silicon houses, a fancy microprocessor is often used as a draw card, as the real profit comes from luring customers into buying large amounts of memory to go with their relatively inexpensive cpu.
Обратная совместимость. С маркетинговой стратегией соседствует и потребность в обратной совместимости. Обратная совместимость означает, что основным способом улучшить архитектуру является добавление новых и, как правило, более сложных функций. Редко инструкции или режимы адресации, удаленные из архитектуры, приводят к постепенному увеличению числа и сложности инструкций в серии компьютеров. Новые архитектуры, как правило, имеют тенденцию включать все инструкции, найденные в машинах успешных конкурентов. Возможно, это происходит потому, что разработчики и покупатели не имеют никакого реального представления о том, что определяет «хороший» набор инструкций.
Поддержка языков высокого уровня. Поскольку использование языков высокого уровня становится все более популярным, производители стали стремиться обеспечить более мощные инструкции для их поддержки. К сожалению, существует мало доказательств того, что какой-либо из более сложных наборов команд фактически предоставил такую поддержку. Наоборот, мы будем утверждать, что во многих случаях сложные наборы инструкций являются более вредными, чем полезными. Усилия, направленные на поддержку языков высокого уровня, похвальны, но мы считаем, что часто внимание разработчиков было сосредоточено на неправильных вопросах.
Использование многозадачности. Разделение времени требуется, чтобы компьютеры могли реагировать на прерывания с возможностью остановить процесс выполнения и перезапустить его позже. Управление памятью и страницами памяти дополнительно требуется, чтобы инструкции могли быть остановлены до завершения, а затем перезапущены. Хотя ни один из них не оказал большого влияния на разработку самих наборов инструкций, они оказали прямое влияние на реализацию. Сложные инструкции и режимы адресации увеличивают описание состояние процессора, которое должно быть сохранено при получении прерывания. Сохранение этого состояния часто предполагает использование теневых регистров и значительное увеличение сложности микрокода. Эта сложность сильно упрощается на машине без сложных инструкций или режимов адресации.
Как используется CISC?
Одним из интересных результатов роста стоимости программного обеспечения является возрастающая зависимость от языков высокого уровня. Одним из следствий этого является то, что автор компилятора заменяет программиста на языке ассемблера в принятии решения о том, какие инструкции будет выполнять машина. Компиляторы часто не могут использовать сложные инструкции и не используют коварные приемы, которыми восхищаются программисты на ассемблере. Компиляторы и программисты на ассемблере также правомерно игнорируют те части набора инструкций, которые бесполезны при данных компромиссах между временем и пространством. В результате часто используется довольно небольшая часть архитектуры.
Например, измерения на конкретном компиляторе IBM 360 показали, что на 10 инструкций приходится 80 % всех выполняемых инструкций, на 16 — 90 %, на 21 — 95 % и на 30 — 99 % [4]. Другое исследование различных компиляторов и программ на ассемблере пришло к выводу, что «небольшая гибкость была бы потеряна, если бы набор инструкций CDC-3600 был сокращен до 1/2 или ¼ доступных сейчас инструкций». [5] Шустек указывает, что на IBM 370 «как уже неоднократно наблюдалось, на очень небольшое количество операций приходится большая часть объёма программы. Программа COBOL, например, выполняет 84 из доступных 183 инструкций, но 48 представляют 99,08% всех выполняемых инструкций, а 26 представляют 90,28%». Аналогичная статистика обнаруживается при исследования использования режимов адресации.
Последствия выбора RISC
Быстрые изменения в технологии и трудности с реализацией CISC привели к нескольким интересным эффектам.
Более быстрая память. Достижения в области полупроводниковой памяти внесли несколько изменений в предположения об относительной разнице в скорости между ЦП и основной памятью. Полупроводниковая память работает быстро и относительно недорого. Недавнее использование кэш-памяти во многих системах еще больше уменьшает разницу между скоростями процессора и памяти.
Иррациональные реализации. Возможно, самым необычным аспектом реализации сложной архитектуры является то, что трудно иметь «рациональные» реализации. Под этим мы подразумеваем, что инструкции специального назначения не всегда быстрее, чем последовательность простых инструкций. Один пример был обнаружен Пеуто и Шустеком для IBM 370 [6] - они обнаружили, что последовательность инструкций загрузки выполняется быстрее, чем инструкция многократной загрузки менее чем для 4 регистров. Этот случай покрывает 40% загрузки нескольких инструкций в типичных программах. Другой случай был найден в VAX-11/780. Инструкция INDEX используется для вычисления адреса элемента массива, одновременно проверяя, соответствует ли индекс границам массива. Очевидно, что это важная функция для точного обнаружения ошибок в операторах языков высокого уровня. Мы обнаружили, что для VAX 11/780, заменив эту единственную инструкцию «высокого уровня» несколькими простыми инструкциями (сравнить, переход, сложение, умножение), мы можем выполнять ту же функцию на 45% быстрее! Кроме того, если компилятор воспользовался случаем, когда нижняя граница была равна нулю, простая последовательность инструкций была на 60% быстрее. Ясно, что меньший код не всегда означает более быстрый код, равно как и инструкции «более высокого уровня» не подразумевают более быстрый код.
Увеличенное время проектирования. Одна из затрат, которую иногда игнорируют, — это время на разработку новой архитектуры. Несмотря на то, что затраты на репликацию CISC могут быть низкими, время проектирования значительно увеличивается. DEC потребовалось всего 6 месяцев, чтобы спроектировать и начать поставку PDP-1, но теперь требуется не менее трех лет, чтобы пройти тот же цикл для такой машины, как VAX.1. Это длительное время разработки может оказать серьезное влияние на качество конечной реализации. Машина либо анонсируется с использованием технологии трехлетней давности, либо проектировщики должны попытаться спрогнозировать хорошую технологию реализации и попытаться внедрить эту технологию при создании машины. Ясно, что сокращение времени проектирования имело бы очень положительные вклад в качество машины.
Увеличение ошибок проектирования. Одной из основных проблем сложных наборов инструкций является отладка проекта; обычно это означает устранение ошибок программ микрокода. Хотя это трудно задокументировать, вполне вероятно, что эти исправления были серьезной проблемой с семейством IBM 360, поскольку почти каждый член семейства использовал хранилище управления только для чтения. Серия 370 использует исключительно изменяемое хранилище управления, возможно, из-за снижения стоимости оборудования, но, скорее всего, из-за неудачного опыта с ошибками на 360. Хранилище управления загружается с гибкого диска, что позволяет поддерживать микрокод аналогично операционным системам. Ошибки исправляются, и выпускаются новые дискеты с обновленными версиями микрокода. Команда разработчиков VAX 11/780 осознала возможность ошибок микрокода. Их решение состояло в том, чтобы использовать программируемый логический массив и 1024 слов Записываемого Хранилища системы Управления (Writable Control Store, WCS) для исправления ошибок микрокода. К счастью, DEC более открыто рассказывает о своем опыте, поэтому мы знаем, что было выпущено более 50 исправлений. Мало кто верит, что все ошибки были найдены.
RISC и СБИС
Разработка компьютеров на одном чипе СБИС делает вышеперечисленные проблемы с CISC даже более важными, чем с их реализациями на нескольких чипах малой интеграции. Несколько факторов указывают на то, что компьютер с сокращенным набором команд (RISC) является разумной альтернативой конструкции.
Осуществимость реализации. Многое зависит от возможности разместить всю конструкцию ЦП на одном кристалле. Сложная архитектура имеет меньше шансов быть реализованной в данной технологии, чем менее сложная архитектура. Хорошим примером этого является серия компьютеров DEC VAX. Хотя модели высокого класса могут показаться впечатляющими, сложность архитектуры делает ее реализацию на одном чипе чрезвычайно сложной с учетом текущих правил проектирования, если не полностью невозможной. Усовершенствование технологии СБИС в конечном итоге сделает возможной версию с одним чипом, но только после того, как будут реализованы менее сложные, но столь же функциональные 32-разрядные архитектуры. Таким образом, компьютеры RISC выигрывают от того, что их можно реализовать в более ранние сроки.
Время проектирования. Сложность проектирования является решающим фактором успеха компьютера СБИС. Если технология СБИС будет продолжать удваивать плотность кристаллов примерно каждые два года, конструкция, на проектирование и отладку которой требуется всего два года, потенциально может использовать гораздо более совершенную технологию и, следовательно, быть более эффективной, чем конструкция, на разработку и отладку которой требуется четыре года. Поскольку срок изготовления новой маски обычно измеряется месяцами, каждая партия ошибок задерживает поставку продукта еще на четверть; распространенными примерами являются задержки на 1-2 года в Z8000 и MC68000.
Скорость. Конечным критерием экономической эффективности является скорость, с которой система выполняет заданный алгоритм. Лучшее использование площади чипа и доступность новых технологий за счет сокращения времени отладки способствуют повышению скорости чипа. RISC потенциально выигрывает в скорости просто за счет более простой конструкции. Удаление одного режима адреса или инструкции может привести к менее сложной структуре управления. Это, в свою очередь, может привести к уменьшению размера управляющих логических схем, уменьшению объема памяти микрокода, уменьшению числа логических вентилей на критическом пути машины. Все это может привести к более быстрому времени второстепенного цикла. Если исключение инструкции или адресного режима заставляет машину ускорить второстепенный цикл на 10%, то добавление должно ускорить машину более чем на 10%, чтобы быть рентабельным. До сих пор мы видели мало веских доказательств того, что сложные наборы инструкций являются экономически эффективными в этом отношении.
Лучшее использование площади кристалла. Если у вас есть большая площадь, почему бы не реализовать CISC? Для заданной площади чипа существует множество компромиссов, которые могут быть реализованы. Мы считаем, что пространство, освобожденное за счет выбора архитектуры RISC, а не CISC, может быть использовано для того, чтобы сделать RISC еще более привлекательным, чем CISC. Например, мы считаем, что общая производительность системы могла бы повыситься еще больше, если бы эта область использовалась для кэш-памяти на кристалле [7], более крупных и быстрых транзисторов или даже для конвейерной обработки. По мере совершенствования технологии СБИС архитектура RISC всегда может оставаться на шаг впереди сопоставимой CISC. Когда CISC станет возможным реализовать на одном кристалле, RISC будет располагать кремниевой областью для использования методов конвейерной обработки; когда CISC получает конвейерную обработку, RISC будет иметь кэш-память на кристалле и т. д. CISC также страдает от того факта, что его внутренняя сложность часто затрудняет реализацию передовых методов.
Поддержка языков высокого уровня
Кто-то может возразить, что упрощение архитектуры — это шаг назад в поддержке языков высокого уровня. В недавней статье [8] отмечается, что архитектура высокого уровня не обязательно является самым важным параметром в создании компьютерной системы с поддержкой языка высокого уровня. Компьютерная система с поддержкой языка высокого уровня (КСЯВУ) определяется как имеющая следующие характеристики:
- Использует языки высокого уровня для всего программирования, отладки и других взаимодействий пользователя с системой.
- Обнаруживает и сообщает об ошибках синтаксиса и времени выполнения в терминах исходной программы на языке высокого уровня.
- Не имеет преобразований из пользовательского языка программирования в какие-либо внутренние языки.
Таким образом, единственной важной характеристикой является то, что сочетание аппаратного и программного обеспечения гарантирует, что программист всегда взаимодействует с компьютером на языке высокого уровня. Программисту никогда не нужно знать о каких-либо более низких уровнях при написании или отладке программы. Пока это требование соблюдено, цель достигнута. Таким образом, для компьютерной системы с языком высокого уровня не имеет значения, реализована ли она с помощью CISC, который "понимает" элементы языка, или если та же реализована с помощью очень быстрой, но простой машиной.
Опыт, полученный нами после изучения компиляторов, показывает, что нагрузка на авторов компиляторов облегчается, когда набор инструкций прост и единообразен. Сложные инструкции, которые предположительно поддерживают функции высокого уровня, часто невозможно использовать в компиляторе. Сложные инструкции все больше склонны к реализации «неправильной» функции по мере повышения уровня инструкции. Это связано с тем, что функция становится настолько специализированной, что становится бесполезной для других операций. Сложные инструкции, как правило, можно заменить небольшим количеством инструкций более низкого уровня, часто практически без потери производительности. Время создания компилятора для CISC дополнительно увеличивается, поскольку вероятность возникновения ошибок при генерации кода для сложных инструкций выше.
Существует немало свидетельств того, что более сложные инструкции, предназначенные для облегчения написания компиляторов, часто не достигают своей цели. Это объясняется несколькими причинами. Во-первых, из-за обилия инструкций существует много способов выполнить данную элементарную операцию, что сбивает с толку как компилятор, так и автора компилятора. Во-вторых, многие разработчики компиляторов предполагают, что имеют дело с рациональной реализацией, хотя на самом деле это не так. В результате «подходящая» инструкция часто оказывается неправильным выбором. Например, занесение регистра в стек с помощью команды PUSHL R0 выполняется медленнее, чем занесение его с помощью команды перемещения MOVL R0,-(SP) на VAX 11/780. Мы можем навскидку придумать еще дюжину примеров для этой и почти любой другой сложной машины. Нужно проявлять особую осторожность, чтобы не использовать инструкцию «потому что она есть». Эти проблемы не могут быть «исправлены» разными моделями одной и той же архитектуры без полного уничтожения либо переносимости программы, либо репутации хорошего автора компилятора, поскольку изменение относительного времени выполнения команд потребует нового генератора кода для сохранения оптимальной генерации кода.
Желание поддержки языков высокого уровня включает в себя как достижение КСЯВУ, так и снижение сложности компилятора. Мы видим несколько случаев, когда RISC значительно хуже, чем CISC, что приводит нас к выводу, что правильно спроектированный RISC кажется разумной архитектурой для поддержки языка высокого уровня.
Работа над RISC-архитектурами
В Беркли. Исследование архитектуры RISC продолжается уже несколько месяцев под руководством Д.А. Паттерсон и К.Г. Секин. Мы чувствуем, что благодаря разумному выбору надлежащего набора инструкций и разработке соответствующей архитектуры можно получить очень простой набор инструкций, который может быть очень быстрым. Это может привести к существенному увеличению общей скорости выполнения программы. Это концепция компьютера с сокращенным набором команд. Реализации RISC почти наверняка будут дешевле, чем реализации CISC. Если мы сможем показать, что простые архитектуры так же эффективны для программиста на языке высокого уровня, как и CISC, такие как VAX или IBM S/38, мы можем заявить, что разработали эффективную конструкцию.
В Bell-labs. Проект по проектированию компьютеров, основанный на исследовании языка программирования C, в течение ряда лет разрабатывается небольшим числом людей в научно-исследовательском центре Bell Laboratories Computing Science. Прототип 16-битной машины был спроектирован и построен А. Г. Фрейзером. 32-битные архитектуры были исследованы С.Р. Борн, Д.Р. Дитцель и С. К. Джонсон. Джонсон использовал итеративный метод предложения машины, написания компилятора, измерения результатов, чтобы предложить лучшую машину, а затем повторения цикла более дюжины раз. Хотя первоначальная цель не заключалась в том, чтобы придумать простую конструкцию, результатом стала 32-битная RISC-подобная архитектура, с плотность кода аналогичной PDP-11 и VAX [9].
В IBM. Несомненно, лучшим примером RISC является мини-ЭВМ 801, разработанный IBM Research в Йорктаун-Хайтс, штат Нью-Йорк [10, 11]. Этому проекту уже несколько лет, и большая группа разработчиков изучала использование архитектуры RISC в сочетании с продвинутым компилятором. Хотя многие детали отсутствуют, их первые результаты кажутся довольно необычными. Они могут тестировать программы в подмножестве PL/I, которое выполняется примерно пять раз производительность модели IBM S/370 168. Мы, безусловно, с нетерпением ждем более подробной информации.
Выводы
Несомненно, есть много примеров, когда отдельные «уникальные» инструкции могут значительно повысить скорость программы. Мы редко видели примеры, когда одни и те же преимущества применимы к системе в целом. Мы считаем, что для широкого спектра вычислительных сред тщательное сокращение набора инструкций приводит к повышению рентабельности реализации. Компьютерные архитекторы должны задать себе следующие вопросы при разработке нового набора инструкций. Если эта инструкция встречается нечасто, оправдана ли она на том основании, что она необходима и не поддается синтезу, например, инструкция вызова супервизора. Если инструкция возникает нечасто и может быть синтезирована, может ли она быть оправдана на том основании, что это операция, занимающая много времени, например, операции с плавающей запятой. Если инструкцию можно синтезировать из небольшого числа более простых инструкций, каково общее влияние на размер и скорость программы, если инструкция будет исключена? Можно ли получить инструкцию бесплатно, например, используя неиспользуемое хранилище управления или используя операцию, уже предоставленную АЛУ? Если его можно получить «бесплатно», какова будет стоимость отладки, документации и стоимость будущих реализаций? Вероятно ли, что компилятор сможет легко сгенерировать инструкцию?
Мы предположили, что стоит свести к минимуму «сложность» (возможно, измеряемую во времени проектирования и элементах) и максимизировать «производительность» (возможно, используя среднее время выполнения, выраженное в задержках вентилей в качестве независимой от технологии единицы времени), при соблюдении определения Компьютерной Системы ЯВУ. В частности, мы считаем, что компьютеры СБИС больше всего выиграют от концепций RISC. Слишком часто быстрое развитие технологии СБИС использовалось как панацея для усложнения архитектуры. Мы считаем, что каждый транзистор будет ценным как минимум в ближайшие десять лет. Хотя тенденция к усложнению архитектуры может быть одним из путей к улучшению компьютеров, в этой статье предлагается другой путь — компьютер с сокращенным набором команд.
Источники
- Utley и др., "IBM System/38 Technical Developments," IBM GS80-0237, 1978.
- J. Cocke, private communication, February, 1980.
- S.S. Husson, Microprogramming: Principles and Practices, Prentice-Hall, Engelwood, N.J., pp. 109-112, 1970.
- W.C. Alexander and D.B. Wortman, "Static and Dynamic characteristics of
XPL Programs," Computer, pp. 41-46, November 1975, Vol. 8, No. 11.
- C.C. Foster, R.H. Gonter and E.M. Riseman, "Measures of Op-Code Utilization," IEEE Transactions on Computers, May, 1971, pp. 582-584.
- B.L. Peuto and L.J. Shustek, "An Instruction Timing Model of CPU Performance," Conference Proc., Fourth Annual Symposium on Computer Architecture, March 1977.
- D.A. Patterson and C.H. Srquin, "Design Considerations for Single-Chip
Computers of the Future," IEEE Journal of Solid-State Circuits, IEEE Transactions on Computers, Joint Special Issue on Microprocessors and Microcomputers, Vol. C-29, no. 2, pp. 108-116, February
- "Retrospective on High-Level Language Computer Architecture," Seventh
Annual International Symposium on Computer Architecture, May 6-8, 1980,
La Baule, France
- S.C. Johnson, "A 32-bit Processor Design," Computer Science Technical
Report # 80, Bell Labs, Murray Hill, New Jersey, April 2, 1
- Electronics Magazine, "Altering Computer Architecture is Way to Raise
Throughput, Suggests IBM Researchers," December 23, 1976, pp. 3
- Datamation, "IBM Mini a Radical Depalrture," October 1979, pp. 53
