АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Проблемы реализации точного прерывания в конвейере

Читайте также:
  1. I. ОБЩИЕ ПРОБЛЕМЫ КАТАЛИЗА
  2. I. Философско-нравственные проблемы
  3. I. Экологические проблемы современного общества
  4. III. Требования к условиям реализации основной образовательной программы дошкольного образования
  5. IV. Социальные проблемы попечения о заключенных.
  6. IX. Выводы и проблемы
  7. Sd мальдигестии с преимущественным нарушением внутриклеточного пищеварения.
  8. V. Ожидаемые результаты реализации Программы
  9. А теперь мое решение проблемы
  10. А- закладка тимуса у человека происходит из клеточного материала 1-2 жаберных карманов,
  11. А.2 Расчет избыточного давления для горючих газов, паров легковоспламеняющихся и горючих жидкостей
  12. А.3 Расчет избыточного давления взрыва для горючих пылей

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

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

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


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

Существует несколько типов конфликтов по данным:

1. Конфликты типа RAW (Read After Write - чтение после записи) -

команда j пытается прочитать операнд прежде, чем команда i запишет на это место свой результат. При этом команда j может получить некорректное старое значение операнда.

Проиллюстрируем этот тип конфликта на примере выполнения команд на рис. 2.

Рис. 2. Конфликт по данным типа RAW

Пусть команды имеют следующий вид:

 

i) ADD R1,R0; R1=R1+R0 i+1=j) SUB R2,R1; R2=R2-R1   Команда i изменит состояние регистра R1 в такте 5. Но команда i+1 должна прочитать значение операнда R1 в такте 4. Если не приняты специальные меры, то из регистра R1 будет прочитано значение, которое было в нем до выполнения команды i.

Конфликты типа RAW обусловлены именно конвейерной организацией обработки команд. Они называются истинными взаимозависимостями.

Уменьшение влияния конфликта типа RAW обеспечивается методом, который называется пересылкой или продвижением данных (data forwarding), обходом (data bypassing), иногда закороткой (short-circuiting).

В этом случае результаты, полученные на выходах исполнительных устройств, помимо входов приемника результата передаются также на входы всех исполнительных устройств микропроцессора (рис. 3).

Рис. 3. Уменьшение влияния конфликта RAW методом продвижения

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

Главной причиной двух других типов конфликтов по данным является возможность неупорядоченного выполнения команд в современных МП, т.е. выполнения команд не в том порядке, в котором они записаны в программе (ложные взаимозависимости).

2. Конфликты типа WAR (Write After Read - запись после чтения):

команда j пытается записать результат в приемник, прежде чем он считается оттуда командой i.

При этом команда i может получить некорректное новое значение операнда:

i) ADD R1,R0; R1=R1+R0

i+1 = j) SUB R0,R2; R0=R0-R2

Этот конфликт возникнет в случае, если команда j вследствие неупорядоченного выполнения завершится раньше, чем команда i прочитает старое содержимое регистра R0.


 

3. Конфликты типа WAW (Write After Write - запись после записи):

команда j пытается записать результат в приемник, прежде чем в этот же приемник будет записан результат выполнения команды i, то есть запись заканчивается в неверном порядке, оставляя в приемнике результата значение, записанное командой i:

 

i) ADD R1,R0; R1=R1+R0

j) SUB R1,R2; R1=R1-R2

Устранение конфликтов по данным типов WAR и WAW достигается путем отказа от неупорядоченного исполнения команд, но чаще всего путем введения буфера восстановления последовательности команд.

Часть конфликтов по данным может быть снята специальной методикой планирования компилятора. В простейшем случае компилятор просто плани-рует распределение команд в базовом блоке - линейном участке программного кода с одним входом и одним выходом, в котором отсутствуют внутренние команды перехода. Т.к. в таком блоке каждая команда будет выполняться, если выполняется первая из них, - можно построить граф зависимостей этих команд и упорядочить их так, чтобы минимизировать приостановки конвейера. Эта техника называется планированием загрузки конвейера (pipeline scheduling) или планированием потока команд (instruction scheduling).

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

● Устранение конфликтов, связанных с ложными взаимозависимостями данных, часто возможно путем переименования регистров (register renaming).

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

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

Таблица 5. Механизм переименования регистров
Команда Действие Рабочий регистр
i Пишет в R0 С этого момента регистру R0 соответствует выделенный для команды регистр PHY0
i+1 Читает из R0 Читает из PHY0
i+2 Пишет в R0 С этого момента регистру R0 соответствует выделенный для команды регистр PHY1
i+3 Читает из R0 Читает из PHY1

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

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

При этом если какая-то команда после i будет писать в тот же логический регистр, ей будет выделен новый физический регистр PHY1, и все команды после нее будут использовать уже новый регистр.

Из табл. 5 видно, что команды стали независимы. Если команды, работающие с логическим регистром R0, зависят друг от друга и их нельзя выполнять параллельно, то микрокоманды "разведены" по физическим регистрам PHY0 и PHY1 и независимы.

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

☺ Однако такой подход требует, чтобы микропроцессор помимо программно доступных архитектурных регистров содержал блок из гораздо большего количества невидимых программисту физических регистров, что реализовано в большинстве современных микропроцессоров. Например, в микропроцессоре Itanium файл физических регистров имеет емкость 128 строк.

►Наличие конфликтов приводит к значительному снижению производительности МП. Определенные типы конфликтов требуют приостановки конвейера. При этом останавливается выполнение всех команд, находящихся на различных стадиях обработки (свыше 30 команд в Pentium 4). ►Другие конфликты, например, при неверном предсказанном направлении перехода, ведут к необходимости полной перезагрузки конвейера. Потери будут тем больше, чем более длинный конвейер используется в МП. Такая ситуация явилась одной из причин сокращения числа ступеней в МП последних моделей. Так, в МП Itanium конвейер содержит всего 10 ступеней.


1 | 2 | 3 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.006 сек.)