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

Ответ 1

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

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

Как для отображения этого формата для "внешних" программ, есть две точки:

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Ответ @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 имеют одинаковый размер. К одному микроплавленному мопу можно добавить 32-битный немедленный и операнд памяти, который использует режим адресации с 2 регистрами и 32-битным смещением. (В SnB и более поздних версиях только режимы однорежимной адресации могут сливаться с операциями ALU)

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

TL; DR резюме:

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

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

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

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

например, xchg eax, ecx на процессорах Intel декодируется как 3 мопа (почему?), и мы лучше всего xchg eax, ecx которые делают tmp = eax; ecx=eax; eax=tmp; 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, поэтому каждое поле регистра в мопе должно быть достаточно широким, чтобы охватить такое количество.

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

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

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

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

Ответ 6

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

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