Переупорядочивание команд
После декодирования команд и переименования регистров команды передаются на исполнение. Как уже отмечалось, выдача команд в функциональные блоки может производиться неупорядоченно, по мере готовности. Поскольку порядок выполнения команд может отличаться от предписанного программой, необходимо обеспечить корректность их операндов (частично решается путем переименования регистров) и правильную последовательность занесения результатов в регистры АРФ. Одним из наиболее распространенных приемов решения этих проблем служит переупорядочивание команд. В его основе лежат использование окна команд — буферной памяти, куда помещаются все команды, прошедшие декодирование, и переименование регистров (последняя операция выполняется только с теми командами, которые записывают свои результат в регистры). Окно команд обеспечивает отсрочку передачи команд на исполнение до момента готовности операндов, а также нужную очередность завершения команд и загрузки их результатов в регистры АРФ. Эта техника известна также под названием шелвинг (shelving). Ниже рассматриваются дна варианта окна команд — централизованное и распределенное.
Централизованное окно команд. Данное окно реализуется в виде так называемого табло (score-board). Техника табло впервые была предложена в 1964 году фирмой Cray и реализована в ЭВМ CDC 6600.
Табло (иногда слово Scoreboard переводят как табельная доска) представляет собой буферное запоминающее устройство, в котором хранится некоторое количество последних извлеченных из памяти и декодированных команд, а также текущая информация о доступности ресурсов, привлекаемых для их исполнения. Функциями табло являются оперативное выявление команд, для исполнения которых уже доступны все необходимые операнды и ресурсы, и выдача таких команд на исполнение в соответствующие функциональные блоки. Табло можно рассматривать как систему предварительной диспетчеризации команд, однако оно осуществляет контроль выполнения команд и после их выдачи.
Все извлеченные из памяти команды сразу же после их декодирования и, если это необходимо, переименования регистров заносятся в табло, причем с соблюдением порядка их следования в программе. Физически табло реализуется на основе ассоциативной памяти. Каждой команде выделяется одна ячейка, состоящая из нескольких полей:
■ поля операции, где хранится дешифрированный код операции;
■ двух полей операндов, размещающих значения операндов, если они известны, либо информацию о том, откуда эти операнды должны быть получены;
■ поля результата, указывающего регистру, куда должен быть помещен результат выполнения данной команды;
■ поля битов достоверности.
■ В табло также хранится текущая информация о доступности устройств обработки (функциональных блоков).
Функционирование табло тесно увязано с работой буфера переименования и может быть описано следующим образом. Каждая команда после декодирования и переименования регистров заносится в очередную свободную ячейку табло. Декодированный код операции помещается в поле операции. Если команда предполагает загрузку результата в регистр, то на этот регистр имеется ссылка в БП и в поле результата заносится номер входа БП, в котором хранится последняя ссылка па данный регистр. Далее делается попытка заполнить поля операндов значениями операндов. Сначала производится поиск нужного значения в аппаратном регистровом файле. Если бит ЗД регистра операнда в АРФ установлен в 0 (значение недостоверно), это означает, что операндом является результат предыдущей операции и дальше следует искать в БП. Выполняется ассоциативный поиск ссылки на регистр в буфере переименования. При удачном исходе (в найденной ячейке БП биты ЗД и ПП установлены в единицу) требуемое значение операнда берется из буфера переименования. В любом варианте при обнаружении достоверного значения операнда поле операнда ячейки табло заполняется найденным значением, а соответствующий этому полю бит достоверности (ЗД) устанавливается в единицу. Если же значение операнда еще не вычислено, то в поле операнда ячейки табло заносится идентификатор входа буфера переименования, где находится последняя ссылка на искомый регистр, при этом бит достоверности такого поля сбрасывается в 0.
Обновление информации о готовности операндов и доступности функциональных устройств выполняется в каждом цикле процессора.
Команда может быть считана из табло и выдана на исполнение лишь после того как будут занесены значения всех операндов, и лишь при условии, что нужный для исполнения этой команды ФБ свободен. После завершения команды в ФП производится запись полученного результата (если эта команда предполагает данное действие) в ту ячейку буфера переименования, на которую указывает поле результата. Одновременно производится ассоциативный доступ ко всем хранящимся в табло командам и в тех из них, где в полях операндов указан идентификатор обновленного входа БП, этот идентификатор заменяется занесенным в регистр новым значением, с соответствующей коррекцией битов достоверности. Далее завершенная команда покидает табло. Удаление команды из табло является основанием для перезаписи значения результата данной команды в регистр АРФ и удаления соответствующей записи из буфера переименования.
Отметим, что рассматриваемая технология предполагает схему распределения готовых команд по требуемым для их исполнения функциональным блокам, с одновременной проверкой их доступности. Эта функция названа диспетчеризацией.
В примере, приведенном на рис. 9.51, для команд П, 12,13 и 15 известны значения одного из операндов, и они вынуждены ожидать значения второго операнда. Команде 14 известны оба операнда, и при условии доступности ФБ, требуемого для ее исполнения, она вправе быть выдана из окна команд.
Рис. 9.51. Содержимое табло
В каждом такте работы процессора готовыми к выдаче могут оказаться сразу несколько команд, и все готовые команды должны быть направлены в соответствующие функциональные блоки. Если имеется несколько однотипных блоков обработки, то в процессоре должна быть предусмотрена логика выбора одного из них.
После выдачи команды из табло ее позиция освобождается и может быть использована для загрузки повой команды. Вместе с тем необходимо сохранить заданную программой последовательность команд. Эту задачу решают одним из двух методов. В первом из них, именуемом как стек диспетчеризации, после выдачи команд и освобождения позиций в окне последующие команды сдвигаются вниз, заполняя вновь доступные позиции и освобождая верхнюю часть табло. Новые команды всегда загружаются в верхнюю часть табло. В случае второго метода, с так называемым блоком обновления регистров, табло функционирует так же, как очередь типа FIFO, но производится общий сдвиг вниз, включая и освободившиеся позиции. Это упрощает логику работы централизованного окна.
Распределенное окно команд. В варианте распределенного окна команд на входе каждого функционального блока размещается буфер декодированных команд, называемый накопителем команд или схемой резервирования (reservation station). Метод резервирования был разработан Р.Л.Томасуло в 1967 году и впервые воплощен в вычислительной системе IBM 360/91. После выборки и декодирования команды распределяются по схемам резервирования тех ФБ, где команда будет исполняться. В буфере команда запоминается и по готовности выдается в связанный с данным пунктом функциональный блок. Логика работы каждого накопителя аналогична централизованному окну команд. Выдача происходит только после того, как команда получит все необходимые операнды, и при условии, что ФБ свободен. При обновлении содержимого буфера переименования файла производится доступ ко всем накопителям команд, и в них идентификаторы обновленных входов заменяются хранящимися в этих входах значениями операндов.
Отметим одну особенность рассматриваемой схемы: не требуется, чтобы операнд был обязательно занесен в отведенный для него регистр — он может быть ускоренно передан прямо в накопитель команд для немедленного использования или буферизирован там для последующего использования.
Число независимых команд, которые могут выполняться одновременно, варьируется от программы к программе, а также в пределах каждой программы. В среднем число таких команд равно 1 -3, временами возрастая до 5-6. Механизм резервирования ориентирован на одновременную выдачу нескольких команд, что, как правило, легче реализовать с распределенным, а не централизованным окном команд, поскольку темп загрузки распределенных буферов обычно меньше, чем потенциальный темп выдачи команд. Пропускная способность линии связи между централизованным окном команд и функциональными блоками должна быть выше, чем в случае распределенного окна. Однако для централизованного окна характерно более эффективное задействование емкости буфера.
Емкость накопителя команд в каждом функциональном блоке зависит от ожидаемого числа команд для этого блока. Типичный накопитель рассчитан на 1 -3 команды. Если в одной из них одновременно готовы несколько команд, выдача их в ФБ производится в порядке занесения этих команд в накопитель.
Для более детального пояснения процессов, происходящих в технологии накопителей, рассмотрим следующий пример. На рис 9.52 показана схема передачи декодированных команд с переименованными регистрами в накопитель команд. Предполагается, что в рамках одного цикла в накопитель могут быть выданы до двух команд. Буфер переименования представлен регистровым файлом (РгФ). Из РгФ позволено одповрсмен но выбрать по два операнда (RS1, RS2) для каждой из двух команд. Каждый регистр РгФ имеет дополнительный бит достоверности (V), единичное состояние которого свидетельствует о корректности содержимого регистра. Доступные операнды (OSl, OS2) переписываются в соответствующие поля ячеек накопителя (OS1/IS1, Оs2/Is2), при этом биты достоверности этих полей (VS1, VS2) устанавливаются в единицу. Если значение операнда в РгФ недоступно, то в поля (OS1/IS1, Os2/Is2) заносится порядковый номер того регистра, откуда операнд должен быть получен (обозначаются как IS1 и IS2), а в соответствующий бит (VS1 или VS2), записывается 0. Если выдаваемая в регистр команда предполагает запись результата в регистр Ro, то бит достоверности этого регистра в РгФ сбрасывается, тем самым запрещается последующим командам использовать содержимое данного регистра.
Рис. 9.52. Общая схема шелвинга к примеру
После передачи команд в накопитель там производится проверка на наличие команд, для исполнения которых есть все необходимые операнды. Поиск таких команд выполняется путем анализа битов VSl и VS2. Если у команды оба бита в единичном состоянии, то она готова к выдаче в ФБ. При наличии в накопителе только одной команды она сразу выдается в ФБ. Если готовых команд несколько, из них в ФБ пересылается наиболее «старая», то есть поступившая в накопитель первой. После завершения команды ее результат совместно с идентификатором регистра результата (RD) выдается в РгФ и в накопитель для обновления их содержимого. В ходе обновления РгФ вычисленное значение заносится в RD, а бит достоверности регистра результата устанавливается в единицу. С этого момента значение RD доступно в качестве операнда для последующих команд. В накопителе производятся поиск идентификатора RD в полях (OS1/IS1, ОS2/IS2) всех команд и их замена на вычисленное значение. Одновременно состояние бита VS1 (VS2) изменяется на еденицу. Далее выполняются очередной поиск готовых к исполнению команд и nN выдача в ФБ.
Теперь рассмотрим технику переупорядочивания команд с использованием накопителей на примере следующей последовательности команд:
MUL R3, R1, R2 {R3 <- R1xR2}
ADD R5, R2, R3 {R5 <- R2+R3}
ADD R6, R3, R4 {R6 <- R3 + R4}.
После декодирования и переименования регистров команда MUL в цикле i выдается в накопитель (рис. 9.53, а). Одновременно с этим из РгФ выбираются операнды этой команды (R1 и R2). Поскольку биты достоверности регистров операндов (V-биты) показывают, что значения операндов доступны (R1 = 10, R2 = 20), то эти значения будут переданы в накопитель, а биты наличия операндов в накопителе (VS1 и VS2) будут установлены в единицу. Бит достоверности регистра назначения R3 в РгФ сбрасывается с тем, чтобы не допустить доступ к этому регистру последующих команд до тех пор, пока в него не будет помещен результат операции MUL.
Рис. 9.53. К примеру техники переупорядочивания команд с использованием накопителей:
а — выдача команды MUL в накопитель в цикле i и выборка соответствующих операндов;
б — поиск выполнимых команд и диспетчеризация команды MUL в цикле i + 1
В следующем (i + 1)-м цикле происходит передача команды из накопителя (этот этап принято называть диспетчеризацией) в функциональный блок (ФБ) и выдача в накопитель двух очередных команд ADD. Сначала делается проверка битов наличия операндов (VSl и VS2) у всех находящихся в накопителе команд (в нашем примере здесь только одна команда MUL). Поскольку оба операнда доступны (VS1 = 1 и VS2 = 1), команда MUL пересылается в ФБ на исполнение. Это иллюстрирует рис. 9.5.3, б.
Рис. 9.54. К примеру техники переупорядочивания команд с использованием накопителей;
а — выдача двух последующих команд ADD в накопитель в цикле i + 1; 6 — проверка
на наличие исполнимых команд в цикле i + 2
В том же (i + 1)-м цикле в накопитель передаются две последующие команды ADD (pис. 9.54, а), при этом имеют место два действия. Во-первых, в РгФ сбрасываются биты достоверности выходных регистров этих команд (R5 и R6). Во-вторых, делается попытка выбрать из РгФ значения операндов команд ADD. В пашем случае биты достоверности в РгФ показывают, что доступны значения регистров R2 и R4, поэтому в накопитель будут отправлены значения данных регистров, а соответствующие им биты VS1 и VS2 будут установлены в единицу. В то же время значение R3 пока недоступно, так как бит достоверности этого регистра содержит 0. Как следствие, вместо значения регистра R3 в накопитель будет передан порядковый номер этого регистра в регистровом файле, а биты VSl и VS2, относящиеся к регистру R3, будут сброшены в 0.
В цикле i + 2 в накопителе снова происходит поиск готовых к исполнению команд с целью их диспетчеризации в ФБ. Поскольку значение R3 еще не вычислено, новые команды в ФБ не выдаются (рис. 9.54, 6).
В цикле i + 3 выполнение команды MUL завершается. На выходе ФБ появляется результат операции (200), а из накопителя поступает идентификатор регистра, куда этот результат должен быть занесен (рис 9.55 а). Теперь настало время обновления состояния регистрового файла и накопителя. В регистр R3 регистрового файла заносится значение 200, а бит достоверности этого регистра устанавливается в 1. С данного момента содержимое R3 может использоваться последующими командами. В накопителе производится ассоциативный и поиск ссылок на регистр R3 во всех полях операндов (OSI/IS1, OS2/IS2) и замена ссылок назначение операнда(200). Одновременно соответствующие биты наличия (VS1, VS2) устанавливаются в единицу. Далее в том же цикле выполняется поиск в накопителе готовых к исполнению команд (рис, 9.55, б). К его началу к диспетчеризации готовы обе команды ADD, то есть более одной команды, и выбор обуславливается правилом арбитража, согласно которому на исполнение в ФБ выдается наиболее «старая» из команд — та, которая поступила в накопитель раньше.
Рис. 9.55. К примеру техники переупорядочивания команд с использованием накопителей:
а — обновление состояния регистрового файла и накопителя результатом команды MUL
в цикле i + 2; б — проверка на наличие исполнимых команд в цикле i + 3 и диспетчеризация
более «старой» из команд ADD
Буфер восстановления последовательности. Стратегия буфера восстановления последовательности (БВП) впервые была описана Смитом и Плескуном (Smith and Pleszkun) в 1988 году. Хотя первоначально она предназначалась для решения проблемы прерывании, в наши дни — это универсальный инструмент для поддержания правильной последовательности исполнения команд в случае нескольких параллельно работающих функциональных блоков.
БВП представляет собой кольцевой буфер (рис. 9.56) с указателями головной и хвостовой части. Указатель головной части содержит адрес, следующего свободного входа. Команды заносятся в БВП в порядке, определяемом программой. Каждая выданная команда помещается в следующую свободную ячейку буфера (говорят, что команде выделен очередной свободным вход БВП.), причем выделение ячеек идет с соблюдением последовательности выдачи команд. Каждый занятый вход содержит также информацию о состоянии хранимой в нем команды: команда только выдана (i), находится в стадии исполнения (х) или уже завершена (f). Указатель хвостовой части показывает па команду, подлежащую удалению из БВП прежде других. Удаление команды разрешено, только если она завершена и предшествующие ей команды уже удалены из буфера. Этот механизм гарантирует что команды покидают БВП строго по порядку. Очередность выполнения команд программы сохраняется благодаря тому, что заносить свои результаты в память или регистры разрешается лишь тем командам, которые покинули БВП.
Число входов в БВП в разных процессорах составляет от 5 (PowerPC 603) до 64(SPAKC64).
Название буфера подчеркивает его основную задачу — поддержание строгой последовательности завершения команд путем переупорядочивания тех из них, которые исполнялись с нарушением этой последовательности. Однако БВП более универсален - с равным успехом он годится и для переименования регистров, и для распределения декодированных команд по накопителям (схемам резервирования). Так, по своему основному назначению БВП применен в микропроцессорах PowerPC 603, PowerPC 604, R10000. В микропроцессорах Am29000, AMD K5, Pentium Pro буфер используется также для переименования регистров. Наконец, в системе Lighining БВП реализует все три из вышеперечисленных функций.
Рис. 9.56. Принципы организации буфера восстановления последовательности