Зачем кому-то нужен CISC?

В нашей лекции о компьютерных системах мы познакомились с процессором MIPS. Он был (пере) разработан в течение срока действия термина и на самом деле довольно легко понять. Он использует дизайн RISC , то есть его элементарные команды регулярно кодируются, и их всего несколько, чтобы сохранить простоту подключения.

Было отмечено, что CISC придерживается другой философии. Я кратко посмотрел на набор инструкций x86 и был шокирован. Я не могу представить, как кто-то захочет построить процессор, использующий столь сложный набор команд!

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

Существует общая историческая тенденция.

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

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

MIPS - это лучшая архитектура RISC, поэтому она так часто преподается.

Семейство x86 немного отличается. Первоначально это была архитектура CISC, предназначенная для систем с очень маленькой памятью (без места для больших инструкций), и претерпела много последовательных версий. Сегодняшний набор команд x86 сложен не только потому, что это CISC, но и потому, что это действительно 8088 с 80386 с Pentium, возможно, с процессором x86_64.

В современном мире RISC и CISC больше не являются черно-белым различием, которым они могли когда-то быть. Большинство архитектур ЦП эволюционировали до разных оттенков серого.

На стороне RISC некоторые современные варианты MIPS добавили инструкции умножения и деления с неоднородным кодированием. Процессоры ARM стали более сложными: многие из них имеют 16-разрядный набор команд Thumb в дополнение к «оригинальным» 32-разрядным инструкциям, не говоря уже о Jazelle для выполнения инструкций JVM на процессоре. Современные процессоры ARM также имеют SIMD- инструкции для мультимедийных приложений: некоторые сложные инструкции все-таки платят.

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

Так почему же самые быстрые процессоры остаются за пределами CISC? Частично, в случае семейства x86 (32-разрядных и 64-разрядных), историческая совместимость. Но это еще не все. В начале 2000-х Intel попыталась продвинуть архитектуру Itanium . Itanium - крайний случай сложных инструкций (хотя на самом деле не CISC: его дизайн был назван EPIC ). Это даже устраняет старомодную идею выполнения инструкций в последовательности: все инструкции выполняются параллельно до следующего барьера. Одна из причин, по которой Itanium не принял это, заключается в том, что никто, будь то в Intel или где-либо еще, не мог написать достойный компилятор для него. Теперь старый добрый в основном последовательный процессор, такой как x86_64, это то, что мы понимаем.

Набор команд x86 - это особый случай. Я думаю, что Motorola 68K и DEC VAX - несколько лучшие примеры CISC. В дни большого количества кода на ассемблере люди думали, что лучше использовать очень регулярный, очень инклюзивный ISA: я считаю, что они назвали разницу между ассемблерным кодом и тем, как люди думают, « семантическим разрывом ». Теоретически, вы хотели, чтобы набор инструкций соответствовал вашим представлениям.

Другой важный драйвер для CISC - это «ортогональность»: каждая инструкция будет работать с каждым режимом адресации (регистр, абсолютный адрес, относительное смещение и т. Д. И т. Д.). Вы можете увидеть призрачного человека с ортогональностью, который появляется в дизайне API в Distributed Computing Environment (DCE) и в CORBA. Эта идея не ограничивается дизайном набора команд.

Одной из причин CISC было плотное кодирование для команд (память была дорогой). Идея RISC заключалась в том, чтобы ускорить ЦП, постоянно выбирая инструкции одного и того же размера (без сложного, медленного шага «вычислить размер инструкции»), чтобы они делали простые вещи (поэтому быстро выяснить, что делать) , Память была дешевой. Это освободило область схем на ЦП для других вещей (больше регистров, больше блоков обработки, поэтому несколько команд могли бы выполняться параллельно, если бы они были независимыми). Поскольку процессор был намного медленнее, чем ОЗУ, это окупилось. Но процессоры стали быстрее (и делали больше параллельно, и ...), в то время как оперативная память не стала быстрее (по крайней мере, не с той же скоростью, что потребление данных процессором из-за увеличения параллелизма). Встречайте кеш-память, быструю как процессор, но небольшую. Так что теперь память снова стоит дорого, не по соображениям стоимости, а по скорости. Время возрождения CISC. Между тем, процессоры стали более сложными, до такой степени, что сегодняшний микропроцессор делает многое из того, что делал компилятор RISC: разбивает операции на элементарные части, переупорядочивает внутренние инструкции RISCy, чтобы они могли выполняться одновременно, когда это возможно. RISC был обижен как "Relief Важные вещи в компилятор" по причине ...

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

Например, чтобы выполнить R1 = R2 + R3 + R4 + R5 + R6и поместить результат в стек, скажем, код RISC записан в виде

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

и как таковой требует 16 байтов пространства.

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

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

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

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

Микропроцессоры были новинкой устройства, когда я вышел на поле. В семидесятые и в начале восьмидесятых годов очень распространенной практикой было собирать ЦП с использованием ALU с битовыми срезами, блока управления на основе микросеквенсора и хранилища управления, в которое был загружен или разорван набор микрокодированных команд. Эти компьютеры были основаны на транзисторно-транзисторной логике серии 7400 (TTL). 78181 4-битный ALU использовался для создания множества процессоров, включая компьютеры DEC PDP-11 и более ранние VAX 11, Data General Nova, Xerox Alto и настольный компьютер Wang.

Вам будет сложно найти любой настольный компьютер, который не использует x86-совместимый процессор. Этот набор команд побил MIPS, он победил Sparc, он победил Alpha, он победил Titanic (возможно, я написал это имя неправильно). MIPS, с другой стороны, сегодня практически не существует. Поэтому независимо от того, что вы думаете сегодня, очень умные люди думали, что набор инструкций x86 был действительно хорошей идеей, и они заработали на этом кучу денег.

Компьютеры начинались как RISC, потому что сложный набор команд был просто за пределами возможностей разработчиков. Если вы хотите увидеть набор команд RISC, посмотрите на набор команд CDC 6400-6600 и CDC Cyber ​​170-175. Это правильный RISC. Около 10 лет назад я спросил некоторых разработчиков чипов, сколько места потребуется (в углу разумного продвинутого чипа GPU). Они сказали мне о 1 мм2 - включая оперативную память машины, которая заняла бы 99% этого пространства.

Когда люди могли создавать машины CISC, у них было преимущество. Помните, что x86 был выпущен задолго до MIPS, 1978 против 1985 года. В то время вам требовались циклы процессора для чтения инструкций, их декодирования и выполнения. MIPS в 1978 году занял бы четыре цикла на инструкцию и на операцию. Если вы возьмете инструкцию x86, такую ​​как «добавить регистр в память», это может занять 7 циклов, но выполнить 3 операции. Это было серьезным преимуществом. И чем больше у вас разных инструкций и чем мощнее каждая инструкция, тем больше ее преимущество.

И когда был разработан 64-битный набор команд x86 с его кошмарными префиксными кодами, сложность набора инструкций больше не имела значения. CISC в настоящее время просто переводится на RISC, и весь переводческий бизнес составляет, возможно, один процент от фишки.

Этот вопрос имеет непосредственное отношение к самым последним тенденциям в области вычислительной техники, которые способствуют массовому переходу на мобильные и планшетные компьютеры, тем самым благоприятствуя процессорам RISC, и ставят Intel (вероятно, крупнейшего поставщика CISC в мире) в невыгодное положение в так называемом «перегибе». Точка " точно так же, как та, на которую Гроув обратил внимание и предупредил. Короткая история заключается в том, что CISC, похоже, начинает таять под воздействием огромного количества мобильных вычислений, которые меняют парадигму и меняют игру из-за, по-видимому, высокого энергопотребления.

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

Отличным примером этого вопроса является чтение Майка Белла, который работает на Intel на новой должности, пытаясь лучше позиционировать Intel на рынке мобильной связи с помощью процессора Atom с помощью проекта / инициативы, подобной «скунс-рунгу», с очень сильным руководителем. поддержка. Рынок мобильной связи тесно связан с архитектурой RISC и, в основном, процессорами ARM, в основном из-за их высокой энергоэффективности (энергопотребления), нового ключевого критерия для вычислений, о котором вопрос и другие ответы не упоминаются. Вот две недавние статьи в этом направлении, которые раскрывают большую часть внутреннего корпоративного мышления (и последующей схватки!) На эту тему:

• Intel отклоняет «налог на x86», не видит будущего для ARM или любого из ее конкурентов

• Империя наносит ответный удар: Intel завоевывает мобильный рынок

Фактор, не упомянутый в других ответах, является экономическим. Это тоже про Intel. Архитектура CISC в основном представлена ​​семействами x86 и x64. Все они происходят от скромного 8088, использованного в оригинальном IBM PC. Раннее доминирование на рынке этой серии компьютеров означало, что у Intel был солидный поток дохода на исследования и разработки. В сочетании с тем фактом, что Intel смогла обуздать конкуренцию, отказавшись от / отменив соглашения о втором источнике, это означало, что цены на процессоры могут вырасти до экстремальных уровней, что обеспечит очень высокую валовую прибыль.

Таким образом, в то время как другие производители процессоров старались не отставать, Intel смогла потратить миллиарды долларов на разработку более новых и более быстрых продуктов. Конкурс RISC не мог потратить почти столько же денег. Многие RISC процессоры ушли с рынка. Некоторые были:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (для ПК), Hitachi SuperH ...

Я вспоминаю экспертов той эпохи, объявляющих, что война RISC против CISC закончилась и CISC победил. Это не было. Это просто потратило на всех остальных.

Может ли эта динамика когда-нибудь измениться? Это уже есть. Никакое экономическое преимущество не является абсолютным.

Ахиллесова пята x86 - это жадный аппетит к власти. Это позволило меньшему, более проворному конкуренту (ARM) процветать на рынках (таких как телефоны / планшеты / и т. Д.), Где экономия энергии имела значение.

Отличное видео об этом от члена команды ARM - Процессор ARM - сеять семена успеха - Computerphile около 8:30

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

Сегодня основанные на ARM системы на чипах (SOC) и конкурирующие чипы x64 от AMD вновь делают рынок процессоров интересным. (ИМХО)

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

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

Исторической (и, на мой взгляд, ошибочной) причиной выбора CISC было закрытие семантического разрыва между программистами, использующими язык более высокого уровня, и процессором. Поскольку сложные инструкции, как правило, могут быть заменены последовательностью более простых инструкций, сложность компилятора языка более высокого уровня для RISC не должна быть намного более сложной, чем для CISC, соответствующей языку. RISC позволяет избежать «семантического столкновения» (когда инструкция процессора выполняет большую или меньшую работу, чем соответствующий оператор языка) и способствует снижению прочности и оптимизации планирования. (См. «Какие компромиссы в усилиях по разработке компилятора, связанных с CISC и RISC?» Для получения более подробной информации.)

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

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

Возможность поставки оптимизированной стандартной библиотеки с процессором имеет значительные преимущества. Хранение и исполнение стандартной библиотеки платформы может быть значительно оптимизировано с помощью программно-аппаратного кодирования. Различие между сложной инструкцией и вызовом уровня абстракции платформы может быть тонким (или вообще отсутствовать). Проект RISC мог бы использовать те же методы реализации для обработки вызовов PAL, что и CISC для сложных команд, включая использование операций, не предусмотренных в общем наборе команд со специализированным оборудованием, использование умного кэширования и декодирования и указание операндов регистра (хотя CISC мог бы часто используют выделенные регистры, похожие на ABI для каждой функции). Ментальная модель, связанная с CISC, может способствовать такой оптимизации. Кроме того, пользователи могут меньше обижаться на принудительное включение "

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

Дополнительная контекстная информация может облегчить оптимизацию оборудования. Например, при увеличении значения в памяти аппаратное обеспечение может распознать, что адрес памяти используется дважды (для нагрузки и хранилища), предоставляя возможность для кэширования, запоминания и трансляции. Сложные инструкции могут предоставить такую ​​информацию явно. В сложной инструкции промежуточные значения имеют явное время жизни (время жизни инструкции); с традиционным регистром RISC значения должны быть явно перезаписаны, чтобы указать конец жизнеспособности. (Примечание: RISC может указывать регистр, который всегда обнуляется после каждого использования, предоставляя средство для указания временного значения одноразового использования. Такие инструкции были бы несколько более сложными.)

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

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

Аналогичным образом, сложная инструкция может обеспечить контролируемый доступ и / или использование привилегированной информации. Поскольку выполняемая операция имеет управляемую семантику, фактического нарушения привилегий можно избежать. RISC-ориентированные альтернативы включают в себя код PAL (который обычно имеет значительные накладные расходы) и маскированный доступ к регистрам конфигурации (или теневым копиям регистров), которые имеют некоторое привилегированное состояние. Предоставить общее решение (RISC) сложнее, чем предоставить решение для одного или нескольких особых случаев (CISC), но оно является более мощным и менее уязвимым для накопления особых случаев. Если считать, что важных особых случаев немного, CISC может быть более привлекательным.

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

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

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

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

Частота расширения x86 также может быть частично приписана его популярности для вычислений общего назначения и модели торгового процессора (это также увеличивает важность двоичной совместимости). ISA RISC часто привязаны к поставщикам sysem, что поощряет более узкую направленность на приложения, а отсутствие конкуренции за реализации конкретного ISA RISC несколько препятствует использованию расширений набора инструкций для маркетинга. Популярность также делает затраты на разработку новых расширений менее значительными (единовременные расходы менее важны при больших объемах).

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

Сравнение академической презентации классического MIPS (который является подмножеством современных версий MIPS и исключает различные дополнительные расширения ISA) с современным x86 (который отслеживает двоичную совместимость с 16-битной 8086 и квази-совместимость на уровне сборки еще дальше) При всем своем историческом багаже ​​это не лучший случай для CISC и не реалистичный случай для RISC.

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

CISC CPU имеет больше преимуществ, чем RISC. Потому что CISC использует меньше аппаратного регистра и шлюзов XNOR / XOR, чем RISC много раз !!!! Представьте, что байты инструкций в CISC будут выполняться-последовательность, есть только один логический вентиль и регистр используется. Если 1 миллиардный транзистор может произвести около 300 миллионов логических элементов, то вы можете обработать 300 миллионов операторов или процессов (IF, равные, математические, переменные, адресация и т. Д.), И в CISC может работать больше программ. Но в RISC для запуска программы в конвейерном проектировании требуется десятки раз логических элементов. Итак, 300 миллионов x 50 раз (50 инструкций) + 15000000000 битовых счетчиков !!! в так называемой RISC. CISC используют больше оборудования, чтобы уменьшить программный алгоритм, который замедляет процессор.