Почему Intel скрывает внутреннее ядро RISC в своих процессорах?
начиная с Pentium Pro (микроархитектура P6), Intel переработала свои микропроцессоры и использовала внутреннее ядро RISC в соответствии со старыми инструкциями CISC. Поскольку Pentium Pro все инструкции CISC делятся на более мелкие части (uops), а затем выполняются ядром RISC.
в начале мне было ясно, что Intel решила скрыть новую внутреннюю архитектуру и заставить программистов использовать "CISC shell". Благодаря этому решению Intel смогла полностью перепроектировать микропроцессоры архитектура без нарушения совместимости, это разумно.
однако я не понимаю одну вещь, почему Intel все еще хранит внутренний набор инструкций RISC, скрытый в течение стольких лет? Почему бы им не позволить программистам использовать инструкции RISC, такие как использование старого набора инструкций x86 CISC?
Если Intel сохраняет обратную совместимость так долго (у нас все еще есть виртуальный режим 8086 рядом с 64-битным режимом), почему они не позволяют нам компилировать программы, чтобы они обходили CISC инструкции и использование RISC core напрямую? Это откроет естественный способ медленно отказаться от набора инструкций x86, который в настоящее время устарел (это основная причина, по которой Intel решила использовать ядро RISC внутри, верно?).
глядя на новые серии Intel 'Core i', я вижу, что они только расширяют набор инструкций CISC, добавляя AVX, SSE4 и другие.
6 ответов:
нет, набор инструкций x86, конечно, не устарела. Он так же популярен, как и всегда. Причина, по которой Intel использует набор RISC-подобных микроинструкций внутри, заключается в том, что их можно обрабатывать более эффективно.
таким образом, процессор x86 работает с довольно мощным декодером в интерфейсе, который принимает инструкции x86 и преобразует их в оптимизированный внутренний формат, который может обрабатывать бэкэнд.
Что касается предоставления этого формата для "внешних" программ, есть два момента:
- это не стабильный формат. Intel может изменить его между моделями ЦП, чтобы наилучшим образом соответствовать конкретной архитектуре. Это позволяет им максимизировать эффективность, и это преимущество было бы потеряно, если бы им пришлось остановиться на фиксированном, стабильном формате инструкций для внутреннего использования, а также для внешнего использования.
- там просто ничего не получится, делая это. С сегодняшним огромным, сложным процессором, декодер является относительно небольшой частью процессора. Необходимость декодирования x86 инструкции делают это более сложным, но остальная часть процессора не затронута, поэтому в целом, есть только очень мало, чтобы получить, особенно потому, что интерфейс x86 все равно должен быть там, чтобы выполнить "устаревший" код. Таким образом, вы даже не сохраните транзисторы, используемые в настоящее время на интерфейсе x86.
Это не совсем идеальное расположение, но стоимость довольно мала, и это гораздо лучший выбор, чем проектирование процессора для поддержки два совершенно разные наборы инструкций. (В этом случае они, вероятно, в конечном итоге изобретут третий набор микро-ops для внутреннего использования, только потому, что они могут быть изменены свободно, чтобы наилучшим образом соответствовать внутренней архитектуре процессора)
Если Intel сохраняет обратную совместимость так долго (у нас еще есть виртуальные Режим 8086 рядом с 64-битным режимом), почему они не позволяют компилировать программы таким образом, они будут обходить инструкции CISC и использовать ядро RISC напрямую? Эта воля открыт естественный способ постепенно отказаться от архитектуры x86 набор инструкций, который является устаревшим в настоящее время (это основная причина, почему Компания Intel решила использовать RISC-ядра внутри, верно?).
вам нужно посмотреть на угол дела этот. Intel фактически пыталась отойти от x86, но это гусь, который несет золотые яйца для компании. XScale и Itanium никогда даже близко не подходили к уровню успеха, который имеет их основной бизнес x86.
то, что вы в основном просите, чтобы Intel разрезала свои запястья в обмен на теплые пушистики от разработчиков. Подрыв x86 не в их интересах. Все, что делает больше разработчиков не нужно выбирать для целевой x86 подрывает x86. Что, в свою очередь, подрывает их.
ответ прост.
основным фактором реализации процессоров RISC было снижение сложности и увеличение скорости. Недостатком RISC является уменьшенная плотность команд, что означает, что один и тот же код, выраженный в формате RISC, требует больше инструкций, чем эквивалентный код CISC.
этот побочный эффект не имеет большого значения, если ваш процессор работает с той же скоростью, что и память, или, по крайней мере, если они оба работают с разумно похожими скорости.
в настоящее время скорость памяти по сравнению со скоростью процессора показывает большую разницу в часах. Текущие процессоры иногда в пять раз или более быстрее, чем основная память.
такое состояние технологии благоприятствует более плотному коду, что-то, что обеспечивает CISC.
вы можете утверждать, что кэши могут ускорить процессоры RISC. Но то же самое можно сказать и о процессорах CISC.
вы получаете большее улучшение скорости с помощью CISC и кэшей, чем RISC и кэш, потому что кэш того же размера оказывает большее влияние на код высокой плотности, который предоставляет CISC.
другой побочный эффект заключается в том, что RISC сложнее для реализации компилятора. Его проще оптимизировать компиляторы для процессоров CISC. так далее.
компания Intel знает, что они делают.
Это настолько верно, что ARM имеет более высокий режим плотности кода, называемый Thumb.
ответ прост. Intel не разрабатывает процессоры для разработчики! Они разрабатывают их для людей, которые делают купив решения, которые кстати, это то, что делает каждая компания в мире!
Intel давно взяла на себя обязательство, что (в разумных пределах, конечно) их процессоры останутся обратно совместимыми. Люди хотят знать, что, когда они покупают новый компьютер на базе Intel, что все их тока программное обеспечение будет работать точно так же, как это было на старом компьютере. (Хотя, надеюсь, быстрее!)
кроме того, Intel знает ровно как важно это обязательство, потому что они однажды попытались пойти другим путем. Точно, сколько людей вы знаете с процессором Itanium?!?
вам это может не понравиться, но это одно решение, чтобы остаться с x86, это то, что сделало Intel одним из самых узнаваемых бизнес-имен в мире!
ответ jalf охватывает большинство причин, но есть одна интересная деталь, о которой он не упоминает: внутреннее RISC-подобное ядро не предназначено для запуска набора инструкций, такого как ARM/PPC/MIPS. X86-налог оплачивается не только в энергозатратных декодерах, но и в некоторой степени во всем ядре. т. е. это не просто кодировка инструкций x86; это каждая инструкция со странной семантикой.
давайте представим, что Intel создала рабочий режим, в котором поток команд было что-то другое, чем x86, с инструкциями, которые отображались более непосредственно на uops. Давайте также представим, что каждая модель процессора имеет свой собственный ISA для этого режима, поэтому они по-прежнему могут изменять внутренние элементы, когда им нравится, и выставлять их с минимальным количеством транзисторов для декодирования команд этого альтернативного формата.
предположительно, у вас все равно будет только одно и то же количество регистров, сопоставленных с архитектурным состоянием x86, поэтому ОС x86 могут сохранять / восстанавливать его на контекстных переключателях без использование набора инструкций для конкретного процессора. Это, вероятно, не слишком сложно, поскольку аппаратное обеспечение для переименования регистра уже существует. (внутренние uops фактически ссылаются на файл физического регистра, но наш гипотетический RISC ISA не должен был бы).
Если у нас просто есть альтернативные декодеры без изменений на более поздних стадиях конвейера (исполнительных устройств), у этого ISA все равно было бы много эксцентричностей x86. это была бы не очень хорошая архитектура RISC. Ни одна инструкция не будет будет очень сложно, но некоторые другие сумасшествия x86 все равно будут там.
например: сдвиги влево/вправо оставляют флаг переполнения неопределенным, если количество сдвигов не равно единице, и в этом случае= обычное обнаружение переполнения со знаком. Подобное сумасшествие для вращается. Однако открытые инструкции RISC могут обеспечивать сдвиги без флагов и т. д. (позволяя использовать только один или два из нескольких uops, которые обычно входят в некоторые сложные инструкции x86). Так что это не совсем так в качестве главного контраргумента.
Если вы собираетесь создать совершенно новый декодер для RISC ISA, вы можете выбрать и выбрать части инструкций x86, которые будут представлены в качестве инструкций RISC. Это несколько смягчает x86-специализацию ядра.
кодировка команд, вероятно, не будет фиксированного размера, так как один uops может содержать много данных. Гораздо больше данных, чем смысл, если все insns имеют одинаковый размер. Одиночный микро-сплавленный uop может добавить 32bit непосредственный и операнд памяти, который использует режим адресации с 2 регистрами и 32-битным смещением. (В СНБ и позже, только один-зарегистрировать режимы адресации может микро-взрыватель с ALU ОПС).
uops очень большие, и не очень похожи на инструкции фиксированной ширины руки. Фиксированной ширины набор 32-битных инструкций можно загружать только 16бит immediates одновременно, так что загрузка 32-битного адреса требует загрузки-мгновенная минимум-половина / loadhigh-непосредственная пара. x86 не должен этого делать, что помогает ему не будьте ужасны только с 15 регистрами GP, ограничивающими способность сохранять константы в регистрах. (15-это большая помощь по 7 регистрам, но удвоение снова до 31 помогает намного меньше, я думаю, что найдено некоторое моделирование. RSP обычно не имеет общего назначения, поэтому он больше похож на 15 регистров GP и стек.)
TL;DR резюме:
в любом случае, этот ответ сводится к "набор инструкций x86, вероятно, лучший способ запрограммировать процессор, который должен быть в состоянии запустите инструкции x86 быстро", но, надеюсь, прольет некоторый свет на причины.
почему они не позволяют нам компилировать программы, чтобы они обходили инструкции CISC и напрямую использовали ядро RISC?
В дополнение к предыдущим ответам, еще одна причина сегментации рынка. Считается, что некоторые инструкции реализуются в микрокоде, а не в аппаратном обеспечении, поэтому разрешение кому-либо выполнять произвольные микрооперации может подорвать продажи новых процессоров с "новыми" более производительными инструкциями CISC.