лекции АКС / лекции АКС / Лекция 11_КОНВЕЙЕРНАЯ ОБРАБОТКА КОМАНД
.doc
Тема №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. Сложность схем управления памятью и регистрами, оптимизации работы конвейера резко возрастает с увеличением количества позиций. Это может привести к тому, что схема управления конвейером станет сложнее тех средств, которые реализуют "полезные" операции.
Из всего сказанного следует вывод — конвейерная организация может существенно повысить быстродействие процессора, но требует хорошо продуманных проектных решений, поддерживающих оптимальное соотношение между предполагаемым повышением производительности и сложностью средств реализации.