Тема 7_2010 Конвейерная организация. Конфликты (542584), страница 6
Текст из файла (страница 6)
Чтобы решить эту проблему, можно увеличить количество портов врегистровом файле, но такое решение может оказаться неприемлемым, посколькуэти дополнительные порты записи скорее всего будут редко использоваться.Однако в установившемся состоянии максимальное количество необходимыхпортов записи равно 1. Поэтому в реальных машинах разработчики предпочитаютотслеживать обращения к порту записи в регистры и рассматриватьодновременное к нему обращение как структурный конфликт.Имеется два способа для обхода этого конфликта. Первый заключается вотслеживании использования порта записи на ступени ID конвейера иприостановке выдачи команды как при структурном конфликте.
Схемаобнаружения такого конфликта обычно реализуется с помощью сдвиговогорегистра. Альтернативная схема предполагает приостановку конфликтующейкоманды, когда она пытается попасть на ступень MEM конвейера. Преимуществомтакой схемы является то, что она не требует обнаружения конфликта до входа наступень MEM, где это легче сделать. Однако подобная реализация усложняетуправление конвейером, поскольку приостановки в этом случае могут возникать вдвух разных местах конвейера.Другой проблемой является возможность конфликтов типа WAW.Можно рассмотреть тот же пример, что и на рис. 17.
Если бы команда LD былавыдана на один такт раньше и имела в качестве месторасположения результатарегистр F2, то возник бы конфликт типа WAW, поскольку эта команда выполнялабы запись в регистр F2 на один такт раньше команды ADDD.Имеются два способа обработки этого конфликта типа WAW:Первый подход заключается в задержке выдачи команды загрузки домомента передачи команды ADDD на ступень MEM.Второй подход заключается в подавлении результата операции сложенияпри обнаружении конфликта и изменении управления таким образом, чтобыкоманда сложения не записывала свой результат.
Тогда команда LD можетвыдаваться для выполнения сразу же. Поскольку такой конфликт является редким,обе схемы будут работать достаточно хорошо. В любом случае конфликт можетбыть обнаружен на ранней стадии ID, когда команда LD выдается для выполнения.Тогда приостановка команды LD или установка блокировки записи результатакомандой ADDD реализуются достаточно просто.Таким образом, для обнаружения возможных конфликтов необходиморассматривать конфликты между командами ПТ, а также конфликты междукомандами ПТ и целочисленными командами. За исключением командзагрузки/записи с ПТ и команд пересылки данных между регистрами ПТ ицелочисленными регистрами, команды ПТ и целочисленные команды достаточнохорошо разделены, и все целочисленные команды работают с целочисленнымирегистрами, а команды ПТ - с регистрами ПТ.Таким образом, для обнаружения конфликтов между целочисленнымикомандами и командами ПТ необходимо рассматривать только командызагрузки/записи с ПТ и команды пересылки регистров ПТ.
Это упрощениеуправления конвейером является дополнительным преимуществом поддержанияотдельных регистровых файлов для хранения целочисленных данных и данных сПТ. (Главное преимущество заключается в удвоении общего количества регистрови увеличении пропускной способности без увеличения числа портов в каждомнаборе). Если предположить, что конвейер выполняет обнаружение всехконфликтов на стадии ID, перед выдачей команды для выполнения вфункциональные устройства должны быть выполнены три проверки:1.
Проверка наличия структурных конфликтов. Ожидание освобожденияфункционального устройства и порта записи в регистры, если онпотребуется.2. Проверка наличия конфликтов по данным типа RAW. Ожидание до техпор, пока регистры-источники операндов указаны в качестве регистроврезультата на конвейерных станциях ID/EX (которая соответствует команде,выданной в предыдущем такте), EX1/EX2 или EX/MEM.3. Проверка наличия конфликтов типа WAW. Проверка того, что команды,находящиеся на конвейерных станциях EX1 и EX2, не имеют в качествеместорасположения результата регистр результата выдаваемой длявыполнения команды. В противном случае выдача команды, находящейся наступени ID, приостанавливается.Хотя логика обнаружения конфликтов для многотактных операций ПТнесколько более сложная, концептуально она не отличается от такой же логики дляцелочисленного конвейера.
То же самое касается логики для ускореннойпересылки данных. Логика ускоренной пересылки данных может быть реализованас помощью проверки того, что указанный на конвейерных станциях EX/MEM иMEM/WB регистр результата является регистром операнда команды ПТ. Еслипроисходит такое совпадение, для пересылки данных разрешается прием посоответствующему входу мультиплексора. Многотактные операции ПТ создаюттакже новые проблемы для механизма прерывания.Поддержка точных прерыванийДругая проблема, связанная с реализацией команд с большим временемвыполнения, может быть проиллюстрирована с помощью следующейпоследовательности команд:DIVF F0,F2,F4ADDF F10,F10,F8SUBF F12,F12,F14Эта последовательность команд выглядит очень просто.
В ней отсутствуюткакие-либо зависимости. Однако она приводит к появлению новых проблем из-затого, что выданная раньше команда может завершиться после команды, выданнойдля выполнения позже. В данном примере можно ожидать, что команды ADDF иSUBF завершаться раньше, чем завершится команда DIVF. Этот эффект являетсятипичным для конвейеров команд с большим временем выполнения и называетсявнеочередным завершением команд (out-of-order completion).
Тогда, например, есликоманда DIVF вызовет арифметическое прерывание после завершения командыADDF, мы не сможем реализовать точное прерывание на уровне аппаратуры. Вдействительности, поскольку команда ADDF меняет значение одного из своихоперандов, невозможно даже с помощью программных средств восстановитьсостояние, которое было перед выполнением команды DIVF.Имеются четыре возможных подхода для работы в условиях внеочередногозавершения команд.1.Игнорирование проблемы и использование механизма неточногопрерывания.
Этот подход использовался в 60-х и 70-х годах и все ещеприменяется в некоторых суперкомпьютерах, в которых некоторые классыпрерываний запрещены или обрабатываются аппаратурой без остановки конвейера.Такой подход трудно использовать в современных машинах при наличииконцепции виртуальной памяти и стандарта на операции с плавающей точкойIEEE, которые требуют реализации точного прерывания путем комбинацииаппаратных и программных средств. В некоторых машинах эта проблема решаетсяпутем введения двух режимов выполнения команд: быстрого, но с возможно неточными прерываниями, и медленного, гарантирующего реализацию точныхпрерываний.2.Буферизация результатов операции до момента завершениявыполнения всех команд, предшествовавших данной.
В некоторых машинахиспользуется этот подход, но он становится все более дорогостоящим, еслиотличия во времени выполнения разных команд велики, поскольку становитсябольшим количество результатов, которые необходимо буферизовать. Более того,результаты из этой буферизованной очереди необходимо пересылать дляобеспечения продолжения выдачи новых команд. Это требует большогоколичества схем сравнения и многовходовых мультиплексоров.
Имеются двевариации этого основного подхода. Первая называется буфером истории (historyfile), использовавшемся в машине CYBER 180/990. Буфер истории отслеживаетпервоначальные значения регистров. Если возникает прерывание и состояниемашины необходимо откатить назад до точки, предшествовавшей некоторымзавершившимся вне очереди командам, то первоначальное значение регистровможет быть восстановлено из этого буфера истории. Подобная методикаиспользовалась также при реализации автоинкрементной и автодекрементнойадресации в машинах типа VAX. Другой подход называется буфером будущего(future file).
Этот буфер хранит новые значения регистров. Когда всепредшествующие команды завершены, основной регистровый файл обновляетсязначениями из этого буфера. При прерывании основной регистровый файл хранитточные значения регистров, что упрощает организацию прерывания. В следующейглаве будут рассмотрены некоторые расширения этой идеи.3.Метод заключается в том, чтобы разрешить в ряде случаев неточныепрерывания, но при этом сохранить достаточно информации, чтобыподпрограммаобработкипрерываниямоглавыполнитьточнуюпоследовательность прерывания. Это предполагает наличие информации онаходившихся в конвейере командах и их адресов.
Тогда после обработкипрерывания, программное обеспечение завершает выполнение всех команд,предшествовавшихпоследнейзавершившейсякоманде,азатемпоследовательность может быть запущена заново.Рассмотрим следующий наихудший случай:Команда 1 - длинная команда, которая в конце концов вызывает прерываниеКоманда 2, ... , Команда n-1 - последовательность команд, выполнение которых незавершилосьКоманда n - команда, выполнение которой завершилосьИмея значения адресов всех команд в конвейере и адрес возврата из прерывания,программное обеспечение может определить состояние команды 1 и команды n.Поскольку команда n завершила выполнение, хотелось бы продолжить выполнениес команды n+1.
После обработки прерывания программное обеспечение должносмоделировать выполнение команд с 1 по n-1. Тогда можно осуществить возврат изпрерывания на команду n+1. Наибольшая неприятность такого подхода связана сусложнением подпрограммы обработки прерывания. Но для простых конвейеров,подобных рассмотренному нами, имеются и упрощения. Если команды с 2 по n всеявляются целочисленными, то мы просто знаем, что в случае завершениявыполнения команды n, все команды с 2 по n-1 также завершили выполнение.Таким образом, необходимо обрабатывать только операцию с плавающей точкой.Чтобы сделать эту схему работающей, количество операций ПТ, выполняющихся ссовмещением, может быть ограничено.
Например, если допускается совмещениетолько двух операций, то только прерванная команда должна завершатьсяпрограммными средствами. Это ограничение может снизить потенциальнуюпропускную способность, если конвейеры плавающей точки являются достаточнодлинными или если имеется значительное количество функциональных устройств.Такой подход использовался в архитектуре SPARC, позволяющей совмещатьвыполнение целочисленных операций с операциями плавающей точки.4. Метод представляет собой гибридную схему, которая позволяетпродолжать выдачу команд только если известно, что все команды,предшествовавшие выдаваемой, будут завершены без прерывания.
Этогарантирует, что в случае возникновения прерывания ни одна следующая за нейкоманда не будет завершена, а все предшествующие будут завершены. Иногда этоозначает необходимость приостановки машины для поддержки точныхпрерываний. Чтобы эта схема работала, необходимо, чтобы функциональныеустройства плавающей точки определяли возможность появления прерывания насамой ранней стадии выполнения команд так, чтобы предотвратить завершениевыполнения следующих команд. Такая схема используется, например, вмикропроцессорах R2000/R3000 и R4000 компании MIPS..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
