TL:DR: разные пути на самом деле не такие разные. Большая разница после декодирования - это FP/SIMD и Integer, которые используются в разных планировщиках, хотя для обоих есть инструкции DirectPath.
См. Также описание микроархитектуры Дэвида Кантера в Барселоне (AMD Fam10h). Его схема внешнего интерфейса в K10/K8/Core2 очень актуальна:
Дополнительные ссылки на подобные вещи можно найти в вики-теге x86 на SO
Из микроархитекта Агнера Фога (http://agner.org/optimize/), глава K8/K10:
17.3 Предварительное декодирование и декодирование длины команды
Инструкция может иметь любую длину от 1 до 15 байтов. Границы команд отмечены в кеше кода и скопированы в кэш уровня 2. Поэтому декодирование длины команды редко является узким местом, даже если декодер длины команды может обрабатывать только одну инструкцию за такт.
Это может быть отдельным от генерации другой информации предварительного декодирования, так как Агнер говорит, что информация о длине команды также сохраняется в кэше L2, но другая информация предварительного декодирования должна быть восстановлена при выборке из L2 в L1I.
Кэш-память уровня 1 содержит значительное количество информации предварительного кода. Это включает информацию о том, где заканчивается каждая инструкция, где находится байт кода операции, а также о различиях между одинарными, двойными и векторными инструкциями пути и идентификации переходов и вызовов. Часть этой информации копируется в кэш уровня 2, но не все. Низкая пропускная способность для команд, поступающих из кэша уровня 2, может быть связана с процессом добавления дополнительной информации предварительного кода.
Фактические детали формата хранения дополнительных данных неизвестны. Предположительно, каждая строка кэша L1I имеет несколько дополнительных байтов в массиве данных, помимо 64B содержимого памяти, в каком-то произвольном формате. Похоже, что для обработки углового случая, где каждая инструкция была бы одним байтом, потребовалось бы значительное дополнительное пространство.
Эти отдельные потоки на самом деле не все , что отдельно. Существует три декодера, и они могут либо декодировать до 3 инструкций DirectPath (производя до трех макроопераций), либо может быть декодирована одна инструкция VectorPath.
Агнер Фог говорит:
Векторные инструкции пути менее эффективны, чем одиночные или двойные инструкции, потому что они требуют эксклюзивного доступа к декодерам и конвейерам и не всегда переупорядочивают оптимально. Например:
; Example 17.1. AMD instruction breakdown
xchg eax, ebx ; Vector path, 3 ops
nop ; Direct path, 1 op
xchg ecx, edx ; Vector path, 3 ops
nop ; Direct path, 1 op
Эта последовательность занимает 4 тактовых цикла для декодирования, потому что векторные инструкции пути должны декодироваться отдельно.
(Этот пример для K8. K10 запускает xchg r,r как инструкцию 2 m. Агнер говорит, что только у K8 есть инструкции DirectPath Double (а у K10 есть только один против вектора), но это не соответствует тому, что показывает диаграмма Дэвида Кантера. Он показывает пакетный буфер с пропускной способностью 3 мегапикселя (aka uops) за такт, но входящие в него декодеры могут выдавать 1 или 2 мопа каждый за цикл.
Семейство Bulldozer также имеет двойные инструкции, и его декодеры могут производить до 4 мегапикселей за такт. Таким образом, он может декодировать одну инструкцию Vectorpath, либо 1-1-1-1 (четыре отдельные инструкции Directpath), либо 2-1-1. Это означает, что только первый декодер может обрабатывать двойные инструкции.
Piledriver и более поздние версии также могут декодировать 2-2 шаблона (две последовательные инструкции DirectPath Double).
Райзен имеет кэш UOP для декодированных инструкций. Он может выдавать до 5 инструкций DirectPath Single за такт в свое неработающее ядро. Но если любая из инструкций является двойной инструкцией, она может выполнить 6 мопов за такт. (Таким образом, AVX / AVX2 может стоить этого на Ryzen, даже если он выполняет инструкции 256b как два мопа.)
Стратегия Intel совсем другая:
Они предварительно декодируют длину, но не хранят ее где-либо в течение длительного времени. Декодеры пытаются декодировать, и если инструкция не работает в простом декодере, это многопользовательская команда, и ей придется ждать следующего тактового цикла, чтобы комплексный декодер смог ее обработать.
Сложный декодер может обрабатывать инструкции до 4 мопов напрямую, в противном случае моп должен исходить из микрокода.
