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

Начиная с 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 и другие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ @jalf охватывает большинство причин, но есть одна интересная деталь, о которой он не упоминает: внутреннее 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 имеют одинаковый размер. Один микроплавленный 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.

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

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