Регистрация переименования - Register renaming

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

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

Проблемный подход

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

Для компактного кодирования инструкций большинство наборов инструкций процессора имеют небольшой набор специальных мест, на которые можно ссылаться специальными именами: регистры. Например, архитектура набора инструкций x86 имеет 8 целочисленных регистров, x86-64 имеет 16, много RISC имеют 32, а IA-64 - 128. В процессорах меньшего размера имена этих местоположений соответствуют элементам зарегистрировать файл.

Различные инструкции могут занять разное время; например, процессор может выполнять сотни инструкций, пока выполняется одна загрузка из основной памяти. Более короткие инструкции, выполняемые при невыполненной загрузке, будут завершены первыми, таким образом, инструкции завершаются с нарушением исходного программного порядка. -автоматическое выполнение использовалось в самых последних высокопроизводительных процессорах для достижения некоторого прироста скорости.

Рассмотрим этот фрагмент кода, работающий на вышедшем из строя процессоре:

1 	r1  м[1024]2 	r1  r1 + 23 	м[1032]  r14 	r1  м[2048]5 	r1  r1 + 46 	м[2056]  r1

Инструкции в последних трех строках не зависят от первых трех инструкций, но процессор не может завершить r1  м[2048] до предыдущего м[1032]  r1 выполнено (в противном случае будет записано неверное значение).

Это ограничение снимается изменением названий некоторых регистров:

1 	r1  м[1024]2 	r1  r1 + 23 	м[1032]  r14 	r2  м[2048]5 	r2  r2 + 46 	м[2056]  r2

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

Многие высокопроизводительные процессоры реализуют это переименование аппаратно для достижения дополнительного параллелизма. На целевых объектах без надлежащего обнаружения потока данных хорошие компиляторы будут обнаруживать независимые последовательности команд и выбирать разные регистры во время генерация кода.

Опасности для данных

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

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

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

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

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

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

  • Компилятору очень сложно избежать повторного использования регистров без большого увеличения размера кода. В циклах, например, последовательные итерации должны будут использовать разные регистры, что требует репликации кода в процессе, называемом разворачивание петли.
  • Большое количество регистров требует больше битов для определения регистра в качестве операнда в инструкции, что приводит к увеличению размера кода.
  • Многие наборы инструкций исторически определяли меньшее количество регистров и не могут быть изменены при сохранении обратной совместимости.

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

Архитектурные и физические регистры

Программы на машинном языке определяют чтение и запись в ограниченный набор регистров, указанных в архитектура набора команд (ISA). Например, Альфа ISA определяет 32 целочисленных регистра, каждый по 64 бита, и 32 регистра с плавающей запятой, каждый по 64 бита. архитектурный Регистры.Программы, написанные для процессоров, выполняющих набор инструкций Alpha, будут определять операции чтения и записи этих 64 регистров. Если программист останавливает программу в отладчике, он может наблюдать за содержимым этих 64 регистров (и нескольких регистров состояния) для определения ход машины.

Один конкретный процессор, который реализует этот ISA, Альфа 21264, имеет 80 целых и 72 с плавающей запятой физический На микросхеме Alpha 21264 имеется 80 физически отдельных ячеек, в которых могут храниться результаты целочисленных операций, и 72 ячейки, в которых могут храниться результаты операций с плавающей запятой (на самом деле ячеек даже больше, но те дополнительные места не имеют отношения к операции переименования регистров.)

Следующий текст описывает два стиля переименования регистров, которые различаются схемой, которая содержит данные, готовые для выполнения.

Во всех схемах переименования машина преобразует архитектурные регистры, на которые есть ссылки в потоке команд, в теги. Если архитектурные регистры могут быть указаны от 3 до 5 бит, теги обычно представляют собой числа от 6 до 8 битов. Файл переименования должен иметь чтение порт для каждого ввода каждой инструкции, переименованной в каждом цикле, и порт записи для каждого вывода каждой инструкции, переименованной в каждом цикле. Поскольку размер файла регистров обычно увеличивается пропорционально квадрату количества портов, файл переименования обычно физически велик и потребляет значительную мощность.

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

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

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

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

Файл архитектурного реестра или файл пенсионного реестра (RRF)
Зарегистрированное состояние регистра машины. ОЗУ проиндексировано номером логического регистра. Обычно записывается, поскольку результаты удаляются или фиксируются из буфера переупорядочения.
Будущий файл
Самый спекулятивный регистр состояния машины. ОЗУ проиндексировано номером логического регистра.
Файл активного реестра
Термин группы Intel P6 для Future File.
Исторический буфер
Обычно используется в сочетании с будущим файлом. Содержит «старые» значения регистров, которые были перезаписаны. Если производитель все еще находится в движении, это может быть ОЗУ, индексированное по номеру буфера истории. После ошибочного предсказания перехода необходимо использовать результаты из буфера истории - они либо копируются, либо будущий поиск файлов отключается, а буфер истории - память с адресацией по содержимому (CAM) индексируется по номеру логического регистра.
Буфер переупорядочения (ROB)
Структура, которая последовательно (циклически) индексируется для каждой операции для выполняемых инструкций. Он отличается от буфера истории, потому что буфер переупорядочения обычно идет после будущего файла (если он существует) и перед файлом архитектурного регистра.
Буферы переупорядочения могут быть без данных или с данными.
В ROB Уилламетта записи ROB указывают на регистры в файле физических регистров (PRF), а также содержат другую бухгалтерскую отчетность.
Это также был первый проект Out of Order, сделанный Энди Глю в Иллинойсе совместно с HaRRM.
ROB P6, записи ROB содержат данные; отдельной PRF нет.
Значения данных из ROB копируются из ROB в RRF при выводе из эксплуатации.
Одна небольшая деталь: если в записях ROB есть временная локальность (то есть, если инструкции, близкие друг к другу в последовательности инструкций фон Неймана, записывают обратно близко друг к другу по времени, то может быть возможно выполнить объединение записи для записей ROB и, таким образом, будет меньше портов, чем у отдельный ROB / PRF).
Неясно, имеет ли это значение, поскольку PRF следует хранить в банке.
ROB обычно не имеют ассоциативной логики, и, конечно же, ни один из ROB, разработанный Энди Глю, не имеет CAM.
Кейт Дифендорф настаивал на том, что ROB обладают сложной ассоциативной логикой в ​​течение многих лет.
Первое предложение ROB могло иметь САМ.

Регистровый файл, индексированный тегами

Это стиль переименования, используемый в MIPS. R10000, то Альфа 21264, а в разделе FP файла AMD Athlon.

На этапе переименования каждый архитектурный регистр, на который имеется ссылка (для чтения или записи), просматривается в архитектурно-индексированном переназначить файл.Этот файл возвращает тег и бит готовности. Тег не готов, если есть поставленная в очередь инструкция, которая будет записывать в него, но еще не выполненная. Для операндов чтения этот тег занимает место архитектурного регистра в инструкции Для каждой записи в регистр новый тег извлекается из свободного тега FIFO, и новое отображение записывается в файл переназначения, так что будущие инструкции чтения архитектурного регистра будут ссылаться на этот новый тег. Тег помечается как неготовый, поскольку команда еще не выполнена. предыдущий физический регистр, выделенный для этого архитектурного регистра, сохраняется вместе с инструкцией в переупорядочить буфер, который представляет собой FIFO, содержащий инструкции в программном порядке между этапами декодирования и градации.

Затем инструкции помещаются в различные очереди выдачиПо мере выполнения инструкций теги для их результатов транслируются, и очереди задач сопоставляют эти теги с тегами их неготовых исходных операндов. Соответствие означает, что операнд готов. Файл переназначения также соответствует этим тегам, поэтому что он может пометить соответствующие физические регистры как готовые. Когда все операнды инструкции в очереди задач готовы, эта инструкция готова к выполнению. Очереди задач выбирают готовые инструкции для отправки в различные функциональные блоки в каждом цикле. готовые инструкции остаются в очередях задач. Такое неупорядоченное удаление инструкций из очередей задач может сделать их большими и энергоемкими.

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

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

Станции бронирования

Это стиль, используемый в целочисленной части конструкций AMD K7 и K8.

На этапе переименования каждый архитектурный регистр, на который ссылается чтение, просматривается как в архитектурно-индексированных будущий файл и переименовать файл. Будущее чтение файла дает значение этого регистра, если еще нет невыполненной инструкции для записи в него (т. е. она готова). Когда инструкция помещается в очередь задач, значения читаются из будущего записываются в соответствующие записи на станциях резервирования. Регистрационные записи в инструкции вызывают запись нового, неготового тега в файл переименования. Номер тега обычно назначается последовательно в порядке инструкций - свободный тег FIFO не требуется .

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

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

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

Градация копирует значение из буфера переупорядочения в файл архитектурного регистра. Единственное использование файла архитектурного регистра - восстановление после исключений и ошибочных прогнозов ветвлений.

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

Сравнение схем

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

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

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

Файлы физических регистров, используемые станциями резервирования, обычно сворачивают неиспользуемые записи параллельно с обслуживаемой ими очередью выдачи, что делает эти файлы регистров больше в совокупности, потребляет больше энергии и сложнее, чем более простые файлы регистров, используемые в схеме с тегами. Что еще хуже, каждая запись в каждой станции резервирования может быть записана каждой шиной результатов, так что машина станции резервирования, например, с 8 записями очереди выдачи на функциональный блок, обычно будет иметь в 9 раз больше обходных сетей, чем эквивалентный тег Следовательно, переадресация результатов потребляет гораздо больше энергии и площади, чем в дизайне с тегами.

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

История

В IBM System / 360 Модель 91 была ранней машиной, которая поддерживала выполнение инструкций вне очереди; он использовал Алгоритм Томасуло, который использует переименование регистров.

В МОЩНОСТЬ1 это первый микропроцессор в котором использовалось переименование регистров и исполнение вне очереди в 1990 году.

Оригинал R10000 В дизайне не было ни сворачивающихся очередей задач, ни кодирования с переменным приоритетом, и в результате возникали проблемы с голоданием - самая старая инструкция в очереди иногда не выполнялась до тех пор, пока декодирование обеих инструкций не прекращалось полностью из-за отсутствия регистров переименования, и все остальные инструкции не выполнялись. Более поздние версии дизайна, начиная с R12000 использовал кодировщик с частично переменным приоритетом, чтобы смягчить эту проблему.

Ранние вышедшие из строя машины не разделяли функции переименования и хранения ROB / PRF. В частности, некоторые из самых ранних, такие как RUU Sohi или DCAF Metaflow, объединяли планирование, переименование и хранение в одной и той же структуре.

Большинство современных машин выполняют переименование путем индексации ОЗУ таблицы сопоставления с номером логического регистра. Например, P6 сделал это; будущие файлы делают это и хранят данные в той же структуре.

Однако более ранние машины использовали память с адресацией по содержимому (CAM) в переименовании, например, HPSM RAT или Таблица псевдонимов регистров, по существу, использовали CAM для номера логического регистра в сочетании с различными версиями регистра.

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

В Микроархитектура P6 была первой микроархитектурой Intel, которая реализовала как исполнение вне очереди, так и переименование регистров. Микроархитектура P6 использовалась в микропроцессорах Pentium Pro, Pentium II, Pentium III, Pentium M, Core и Core 2. Cyrix M1, выпущенный 2 октября 1995 г.,[1] был первым процессором x86, в котором использовалось переименование регистров и выполнение вне очереди. Другие процессоры x86 (например, NexGen Nx686 и AMD K5 ), выпущенный в 1996 году, также включал переименование регистров и выполнение RISC вне очереди. μ-операции (а не собственные инструкции x86).[2][3]

Рекомендации

  1. ^ «Процессор Cyrix 6x86».
  2. ^ «NexGen Nx686».
  3. ^ "PC Mag 6 декабря 1994". Зифф Дэвис. 1994-12-06.