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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

Реальный ответ прост.

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

---

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

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

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

---

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

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

---

TL; DR сводка:

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

---

Внутренние форматы UOP в интерфейсе и в фоновом режиме

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

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

например, xchg eax, ecx на процессорах Intel декодируется как 3 мопа ( почему? ), и мы лучше всего предполагаем, что это мовоподобные мопы, которые делают 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), то есть в бэк-энде (послеэтап выпуска / переименования).Каждый из физических файлов регистров int / FP содержит по 168 записей в Haswell , поэтому каждое поле регистра в UOP должно быть достаточно широким, чтобы адресовать такое количество.

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

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

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

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

Answer 6

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

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