Что-то, что мне было интересно некоторое время, но, во-первых, одно из предположений состоит в том, что все микропроцессоры, созданные макрооперацией, могут иметь такой же rip, что и макрооперация (я почти уверен, чтоIQ будет иметь rip для каждого блока IFETCH, и декодеры могут легко преобразовать rip + смещение макрооперации для rip макрооперации на основе информации о длине).IDQ составляет 8 строк по 32 байта для каждого логического ядра в SnB (может быть 64 байта в последних микроархитектурах, но я не уверен), что вызывает вопрос о формате мопов в IDQ - есть ли адресдля каждой строки IDQ и инструкция jmp запускает новую строку, аналогично μop cache ;где, как я понял из стр. 47 руководства по оптимизации, 32-байтовая выровненная область может охватывать 3 пути, но последний путь должен заканчиваться предположительно jmp, чтобы он мог заново инициировать выборкудля следующего окна инструкций путем направления конвейера по этому адресу (который также может вернуться в кэш-память или может запустить устаревший конвейер декодирования).Это позволило бы легко перемещать пути кеша µop в IDQ, если бы IDQ имел одинаковую структуру (поэтому я чувствую, что IDQ может иметь один адрес в начале каждой строки, а не по инструкции, поскольку это не такнеобходимо, если инструкции в строке имеют смежные rip s, а инструкция после перехода, возврата и т. д. будет в новой строке).Это также позволило бы LSD блокировать и обнаруживать циклы более эффективно, поскольку ему нужно было бы только сканировать 8 адресов в начале строк, чтобы проверить, совпадает ли он, например, с адресом jmp.Но опять же, я не уверен, как именно реализован ЛСД;Источники, кажется, фиксируют значение 28 мкс как максимальную петлю, которую можно обнаружить.
Существует также сложность механизма стека и того, как он размещает свои операции синхронизации;чтение раздела тумана Агнера в microarchitecture.pdf в Stack Engine показывает, что μop синхронизации вставляется перед mov или add, что требует синхронизации rsp, поэтому потребуетсяrip этой инструкции в случае, если перед исходным mov или add стоит ret (так что его можно сравнить с rsp для проверки прогноза RSB на любом порту, обрабатывающем ret, BEU?(*)).Я бы также предположил, что Stack Engine работает вместе с декодерами, чтобы он вставлялся одновременно с декодерами, чтобы впоследствии не пришлось сдвигаться вдоль инструкций для его вставки.Также необходимо иметь битовую индикацию в операторе синхронизации, чтобы информировать распределитель о необходимости дисконтировать его байты при вычислении rip s относительно адреса в начале строки при выдаче их в ROB.Он также может начать новую строку для инструкции после операции синхронизации, но это, возможно, кажется дорогим.
Что-то, что останавливает эту логику в тупике, - это просто то, что rip инструкции не может быть получено изсмещение байта μop в строке от адреса в начале строки, поскольку длина макроопераций не совпадает с длиной μop.Эту проблему можно решить, если каждая строка IDQ соответствует одному макрооператору (с любыми операциями синхронизации, добавленными в конец строки, например mov + synchop в одной строке и ret, который я упоминал ранее, в строкетопографически ниже, с rip в начале каждой строки), что, я думаю, расточительно.Единственная альтернатива, о которой я могу подумать, - это пометить адреса в строке для каждой макрооперации, которая кажется грязной.
У кого-нибудь есть что-то, чтобы добавить или исправить, как это может быть реализовано?
(*)Это связано с вопросом о том, как обрабатываются ошибочные прогнозы ветвления, например, когда команда RS с предсказанным-принятым ветвлением назначается RS, один из параметров может быть rip записи ROB команды после того, как она может BEU направить трубопровод по неверному прогнозу. Когда выделяется ret, один из параметров должен быть записью ROB для uop после него, а другой параметр - rsp, чтобы его можно было сравнить с ним.