Почему Intel скрывает внутреннее ядро ​​RISC в своих процессорах?

89

Начиная с Pentium Pro (микроархитектура P6), Intel переработала свои микропроцессоры и использовала внутреннее ядро ​​RISC в соответствии со старыми инструкциями CISC. Начиная с Pentium Pro, все инструкции CISC делятся на более мелкие части (uops), а затем выполняются ядром RISC.

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

Однако я не понимаю одного, почему Intel все еще скрывает набор внутренних инструкций RISC в течение стольких лет? Почему бы им не позволить программистам использовать инструкции RISC, такие как использовать старый набор инструкций x86 CISC?

Если Intel сохраняет обратную совместимость так долго (у нас все еще есть виртуальный режим 8086 рядом с 64-битным), почему они не позволяют нам компилировать программы, чтобы они обходили инструкции CISC и напрямую использовали ядро ​​RISC? Это откроет естественный способ постепенно отказаться от набора инструкций x86, который в настоящее время устарел (это основная причина, по которой Intel решила использовать ядро ​​RISC внутри, верно?).

Глядя на новую серию Intel Core i, я вижу, что они только расширяют набор инструкций CISC, добавляя AVX, SSE4 и другие.

Тупой
источник
1
обратите внимание, что есть определенные процессоры x86, где
доступен

Ответы:

90

Нет, набор инструкций x86 определенно не является устаревшим. Он популярен как никогда. Intel использует набор RISC-подобных микрокоманд внутри компании, потому что они могут быть обработаны более эффективно.

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

Что касается выставления этого формата «внешним» программам, есть два момента:

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

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

Jalf
источник
1
Хорошие моменты. RISC - это хорошая базовая архитектура, где ХОРОШО означает быструю работу и возможность правильной реализации, а x86 ISA с историей архитектуры CISC - это просто макет набора инструкций с огромной историей и невероятным богатством доступного для него двоичного программного обеспечения. , а также эффективен для хранения и обработки. Это не оболочка CISC, это промышленный стандарт ISA.
Уоррен П.
2
@ Уоррен: в последней части я так не думаю. Хорошо разработан набор команд CISC является более эффективным с точки зрения хранения, да, но из нескольких тестов , которые я видел, «средний» инструкции x86 что - то вроде 4,3 байт в ширину, которая больше , чем это было бы обычно в RISC-архитектура. x86 сильно теряет эффективность хранения, потому что он спроектирован и расширен на протяжении многих лет бессистемно. Но, как вы говорите, его главная сила - это история и огромное количество существующего двоичного кода.
jalf
1
Я не сказал, что это «хорошо разработанный CISC», просто «огромная история». ХОРОШИЕ детали - это детали дизайна микросхем RISC.
Уоррен П.
2
@jalf - По результатам проверки реальных двоичных файлов размер инструкции в x86 в среднем составляет около 3 байтов каждая. Конечно, есть гораздо более длинные инструкции, но в реальном использовании, как правило, преобладают более мелкие.
srking
1
Средняя длина инструкции не является хорошим показателем плотности кода: наиболее распространенный тип инструкций x86 в типичном коде - это загрузка и сохранение (просто перемещение данных туда, где они могут быть обработаны, и обратно в память, процессоры RISC и около ½ CISC имеют много регистров, поэтому не нужно делать это много. Также сколько может сделать одна инструкция (инструкции arm могут делать около 3 вещей).
ctrl-alt-delor
20

Настоящий ответ прост.

Основным фактором внедрения процессоров RISC было снижение сложности и увеличение скорости. Обратной стороной RISC является уменьшенная плотность инструкций, это означает, что тот же код, выраженный в формате RISC, требует больше инструкций, чем эквивалентный код CISC.

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

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

Такое состояние технологии способствует более плотному коду, что и обеспечивает CISC.

Вы можете утверждать, что кэширование может ускорить процессоры RISC. Но то же самое можно сказать и о процессорах CISC.

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

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

Intel знает, что они делают.

Это так, что ARM имеет режим с более высокой плотностью кода, называемый Thumb.

Хорхе Альдо
источник
1
Кроме того, внутреннее ядро ​​RISC снижает количество транзисторов в ЦП CISC. Вместо того, чтобы жестко связывать каждую инструкцию CISC, вы можете использовать микрокод для их выполнения. Это приводит к повторному использованию инструкций микрокода RISC для различных инструкций CISC, следовательно, к использованию меньшей площади кристалла.
Sil
16

Если Intel сохраняет обратную совместимость так долго (у нас все еще есть виртуальный режим 8086 рядом с 64-битным), почему они не позволяют нам компилировать программы, чтобы они обходили инструкции CISC и напрямую использовали ядро ​​RISC? Это откроет естественный способ постепенно отказаться от набора инструкций x86, который в настоящее время устарел (это основная причина, по которой Intel решила использовать ядро ​​RISC внутри, верно?).

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

По сути, вы просите Intel разрезать себе запястья в обмен на теплые пушинки от разработчиков. Подрыв x86 не в их интересах. Все, что заставляет больше разработчиков не выбирать x86, подрывает x86. Это, в свою очередь, их подрывает.

Майк Томсен
источник
6
Да, когда Intel попыталась сделать это (Itanium), рынок просто пожал плечами.
Уоррен П.
Следует отметить, что неудача Itanium имела ряд факторов, и не только потому, что это была новая архитектура. Например, передача расписания ЦП компилятору, который никогда не достиг своей цели. Если бы Itanium был в 10 или 100 раз быстрее процессоров x86, он бы продавался как горячие пирожки. Но это было не быстрее.
Katastic Voyage
5

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

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

Более того, Intel точно знает , насколько важно это обязательство, потому что когда-то они пытались пойти другим путем. Сколько именно людей вы знаете с процессорами Itanium?!?

Возможно, вам это не понравится, но именно это решение - остаться с x86 - и сделало Intel одним из самых узнаваемых бизнес-имен в мире!

гео
источник
2
Я не согласен с утверждением, что процессоры Intel не удобны для разработчиков. Программируя PowerPC и x86 в течение многих лет, я пришел к выводу, что CISC гораздо удобнее для программистов. (Сейчас я работаю в Intel, но я принял решение по этому поводу еще до того, как меня приняли на работу.)
Джефф,
1
@Jeff Это не было моим намерением! Вопрос был в том, почему Intel не открыла набор инструкций RISC, чтобы разработчики могли его использовать. Я не говорил ничего о x86 не являясь разработчиком дружелюбным. Я сказал, что такие решения принимались не с учетом интересов разработчиков , а, скорее, были сугубо деловыми решениями.
geo
5

Ответ @jalf охватывает большинство причин, но есть одна интересная деталь, о которой он не упоминает: внутреннее RISC-подобное ядро ​​не предназначено для запуска набора инструкций, например ARM / PPC / MIPS. Налог на x86 уплачивается не только за энергоемкие декодеры, но и в некоторой степени за все ядро. т.е. это не просто кодировка инструкций x86; это каждая инструкция со странной семантикой.

Давайте представим, что Intel действительно создала рабочий режим, в котором поток инструкций отличался от x86, с инструкциями, которые более точно отображались на uops. Давайте также представим, что каждая модель процессора имеет свой собственный ISA для этого режима, поэтому они по-прежнему могут изменять внутренние компоненты, когда им нравится, и открывать их с минимальным количеством транзисторов для декодирования инструкций этого альтернативного формата.

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


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

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

Если вы собираетесь создать совершенно новый декодер для RISC ISA, вы можете попросить его выбрать части инструкций x86, которые будут представлены как инструкции RISC. Это несколько смягчает x86-специализацию ядра.


Кодирование инструкций, вероятно, не будет фиксированным, поскольку отдельные мопы могут содержать много данных. Гораздо больше данных, чем имеет смысл, если все insns имеют одинаковый размер. Один микроплавленный uop может добавить 32-битный непосредственный операнд и операнд памяти, который использует режим адресации с 2 регистрами и 32-битным смещением. (В SnB и более поздних версиях только режимы адресации с одним регистром могут соединяться с операциями ALU).

uops очень большие и не очень похожи на инструкции ARM фиксированной ширины. 32-битный набор инструкций фиксированной ширины может загружать только 16 битов одновременно, поэтому для загрузки 32-битного адреса требуется пара "загрузка-немедленная" низкая половина / загрузка высокая-немедленная. x86 не обязан этого делать, что помогает не быть ужасным: всего 15 регистров GP ограничивают возможность хранения констант в регистрах. (15 - это большая помощь по сравнению с 7 регистрами, но удвоение снова до 31 помогает намного меньше, я думаю, что была обнаружена некоторая имитация. RSP обычно не является универсальным, поэтому он больше похож на 15 регистров GP и стек.)


TL; Резюме DR:

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


Внутренние форматы uop в интерфейсе по сравнению с сервером

См. Также Micro fusion и режимы адресации, чтобы узнать о различиях в том, что форматы интерфейсных и внутренних модулей uop могут представлять на процессорах Intel.

Сноска 1 : Есть несколько «скрытых» регистров для использования микрокодом в качестве временных. Эти регистры переименовываются так же, как регистры архитектуры x86, поэтому многопозиционные инструкции могут выполняться не по порядку.

например, xchg eax, ecxна процессорах Intel декодируется как 3 мупа ( почему? ), и мы предполагаем, что это MOV-подобные мопы tmp = eax; ecx=eax ; eax=tmp;. В таком порядке, потому что я измеряю задержку в направлении dst-> src на ~ 1 такте, а не 2 в другом случае. И эти команды перемещения не похожи на обычные movинструкции; они не кажутся кандидатами на удаление mov с нулевой задержкой.

См. Также http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/, где упоминается попытка экспериментального измерения размера PRF и необходимость учета физических регистров, используемых для хранения архитектурного состояния, включая скрытые регистры.

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

Формат uop несколько отличается внутри ядра вне очереди (ROB и RS), также известного как back-end (после этапа выдачи / переименования). Каждый файл физических регистров int / FP имеет 168 записей в Haswell , поэтому каждое поле регистра в uop должно быть достаточно широким, чтобы адресовать такое количество.

Поскольку переименователь присутствует в HW, нам, вероятно, было бы лучше использовать его, вместо того, чтобы передавать статически запланированные инструкции непосредственно в серверную часть. Таким образом, мы могли бы работать с набором регистров размером с регистры архитектуры x86 + временные памяти микрокода, не более того.

Серверная часть разработана для работы с переименователем внешнего интерфейса, который позволяет избежать опасностей WAW / WAR, поэтому мы не могли бы использовать его как упорядоченный ЦП, даже если бы захотели. У него нет блокировок для обнаружения этих зависимостей; это обрабатывается проблемой / переименованием.

Было бы неплохо, если бы мы могли передавать uops в серверную часть без узкого места на этапе выдачи / переименования (самое узкое место в современных конвейерах Intel, например, 4-х разрядный в Skylake против 4 ALU + 2 порта загрузки + 1 порт хранения в бэкэнд). Но если вы это сделали, я не думаю, что вы можете статически запланировать код, чтобы избежать повторного использования регистров и наступления на результат, который все еще необходим, если из-за промаха кеша загрузка застопорилась на долгое время.

Таким образом, нам в значительной степени нужно направить мопы на этап выдачи / переименования, вероятно, только в обход декодирования, а не кеш-кеш или IDQ. Тогда мы получаем нормальный OoO exec с нормальным обнаружением опасности. Таблица распределения регистров предназначена только для переименования 16 + нескольких целочисленных регистров в целочисленный PRF из 168 записей. Мы не могли ожидать, что HW переименует больший набор логических регистров в то же количество физических регистров; для этого потребуется большая RAT.

Питер Кордес
источник
-3

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

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

КОЛАНИЧ
источник
1
Я не думаю, что это имеет смысл. RISC может использовать микрокод, особенно если мы говорим о простом добавлении декодеров RISC к интерфейсу x86.
Питер Кордес,
2
Это все еще неправильно. Новые инструкции AES (и предстоящие инструкции SHA) и другие вещи, такие как PCLMULQDQ, имеют специальное оборудование. На Haswell AESENC декодирует в один uop ( agner.org/optimize ), поэтому определенно не микрокодируется вообще. (Декодерам нужно только активировать секвенсор микрокода ПЗУ для инструкций, которые декодируют более 4 мопов .)
Питер Кордес
1
Вы правы в том, что некоторые новые инструкции просто используют существующие функции, чего нет в инструкциях x86. Хороший пример может быть BMI2 SHLX , который позволяет делать переменный подсчет изменение без ввода счетчика в CL, и без какого дополнительных микроопераций требуется для обработки семантики флага дерьмового x86 (флаги не модифицируется , если величина сдвига равен нуль, так что SHL r/m32, clимеет входная зависимость от FLAGS и декодируется до 3 мопов на Skylake. Однако, согласно тестированию Агнера Фога, это был только 1 моп на Core2 / Nehalem.)
Питер Кордес,
Спасибо за ваши Коментарии.
КОЛАНИЧ