Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

лекции АКС / лекции АКС / Лекция 11_КОНВЕЙЕРНАЯ ОБРАБОТКА КОМАНД

.doc
Скачиваний:
64
Добавлен:
26.02.2016
Размер:
2.48 Mб
Скачать

5

Тема №12 КОНВЕЙЕРНАЯ ОБРАБОТКА КОМАНД

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

широкое распространение получило еще одно направление в организации процесса обработки команд — конвейерная обработка.

Основы конвейерной организации обработки

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

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

Рассмотрим самую простую схему разделения процесса обработки команды на два этапа — извлечение команды и выполнение команды. При выполнении команды существуют интервалы времени, когда обращение к памяти не произ­водится. Их можно использовать для извлечения следующей команды парал­лельно с выполнением текущей. Этот подход иллюстрируется схемой, представ­ленной на рис. 11.10,а. Конвейер имеет две независимые "рабочие позиции" — извлечения команды и выполнения команды. На первой позиции команда из­влекается из памяти и загружается в буфер. Когда вторая позиция будет свобод­на, первая передаст ей команду из буфера. Пока команда будет выполняться на второй позиции, на первой позиции можно использовать любой свободный цикл обращения к памяти и извлечь следующую команду, загрузив ее в буфер. Этот процесс называется извлечением команды с опережением (instruction prefetch) или наложением извлечения (fetch overlap). Очевидно, что такая организация процесса ускорит обработку команд. Если оба этапа реализуются за одно и то же время, цикл обработки команды сократится вдвое. Но присмотревшись к про­цессу повнимательнее, мы обнаружим, что увеличения скорости обработки вдвое вряд ли можно достичь на практике (рис. 11.10,6). Тому есть две причины.

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

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

Рис. 11.10. Двух позиционный конвейер выполнения команд: а — упрощенное представление; б — детализированное пред­ставление

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

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

Извлечение команды (ИК) — чтение из памяти следующей выполняемой машинной команды.

Декодирование команды (ДК) — расшифровка кода операции и специфи­каторов операндов.

Вычисление адресов операндов (АО) — вычисление исполнительных адре­сов всех операндов-источников. При вычислении эффективных адресов учи­тываются заданные режимы адресации операндов, в том числе косвенная адресация, адресация со смещением, индексная и т.д.

Извлечение операндов (ИО) — Извлечение всех операндов-источников из памяти. Операнды, которые ранее помещены в регистр, в выполнении этого этапа не участвуют.

Выполнение команды (ВК) — выполнение операций, заданных кодом операции в команде и, если это задано в команде, сохранение результата в регистрах.

Запись результата (ЗР) — запись результата в память.

Время выполнения перечисленных этапов примерно одинаковое. Для упро­щения анализа будем в дальнейшем считать, что дело обстоит именно так, — все этапы выполняются за один и тот же интервал времени — назовем его тактом конвейера. На рис. 11.11 показана временная диаграмма работы конвейера опе­раций из шести позиций, который позволяет сократить время выполнения 9 машинных команд с 54 тактов до 14.

Рис. 11.11. Временная диаграмма работы конвейера операций

Эта диаграмма требует некоторых пояснений. Во-первых, при ее по­строении предполагается, что каждая команда проходит все шесть перечис­ленных этапов обработки. Конечно же, в действительности дело обстоит несколько по-другому. Самый простой пример — при обработке команды за­грузки этап ЗР опускается. Но при организации конвейера для упрощения схем управления синхронизация производится таким образом, что каждая команда "задерживается" на этапе определенное время, хотя никакие опера­ции с ней не выполняются. Во-вторых, при построении диаграммы считает­ся, что все этапы можно выполнять параллельно и что при этом, в частно­сти, не может возникнуть конфликт в соперничестве за доступ к памяти. Этапы ИК, ИО и ЗР предполагают обращение к памяти. Из диаграммы сле­дует, что все операции доступа реализуются одновременно, но реальные кон­струкции блоков памяти не позволяют это сделать. Следует, однако учиты­вать, что извлекаемая информация может находиться в кэш-памяти или эта­пы ИО и ЗР при выполнении определенных команд могут опускаться. Следовательно, довольно высока вероятность того, что конфликт в борьбе за доступ к памяти не окажет существенного влияния на скорость работы кон­вейера операций.

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

Предположим, что 3-я команда оказалась командой условного перехода, передающей управление 15-й команде. До тех пор, пока 3-я команда не пройдет "позицию" ВК, никакой информацией о том, на какую команду за­дан переход в ней, схема управления конвейером не располагает. Следова­тельно, до этих пор конвейер работает в обычном режиме — извлекает 4-ю команду и т.д. В том варианте, который показан на рис. 11.11, 3-я команда тоже была командой условного перехода, но заданное условие перехода вы­полнено не было, а потому сохранился естественный порядок выполнения команд и были реализованы все потенциальные преимущества конвейерной организации обработки. В случае, показанном на рис. 11.12, "произошла не­приятность" — заданное в команде условие перехода было выполнено, и ес­тественный порядок выполнения команд был изменен, что выяснилось толь­ко на исходе 7-го такта. После этого пришлось "очистить" все позиции кон­вейера, поскольку выполненные на них операции оказались лишними. На 8-м такте в конвейер была "загружена" 15-я команда, а на интервале от 9-го до 12-го такта ни одна команда с конвейера не "сошла". Это и есть "штраф" за то, что мы не могли предусмотреть действительную передачу управления в программе. На рис. 11.13 показан алгоритм анализа, который должна вы­полнять схема управления конвейером для обнаружения переходов и реаги­рования на прерывания.

Рис. 11.12. Влияние команды условного перехода на работу конвейера операций

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

После знакомства с приведенными выше рассуждениями может пока­заться, что чем большее количество "рабочих позиций" в конвейере (т.е. чем более детально разделен на этапы цикл обработки команды), тем выше будет быстродействие процессора. Однако это не совсем так. Еще при разработке семейства IBM S/360 в 60-х годах конструкторы фирмы указали на два фак­тора, которые сводят на нет, казалось бы, такую простую концепцию повы­шения эффективности. Эти соображения остались справедливыми и поныне.

1. На каждой позиции конвейера существуют определенные накладные расхо­ды, связанные с передачей данных из буфера в буфер и выполнением все­возможных подготовительных операций. Такие накладные расходы могут заметно увеличить время обработки отдельной команды, пока она пройдет все позиции конвейера. Это становится особенно существенным, когда по­следовательные команды логически очень тесно связаны то ли через часто встречающиеся команды условного перехода, то ли через данные, которые одной командой записываются в память, а другой — считываются.

Рис. 11.13. Алгоритм управления конвейером из шести рабочих позиций

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

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