Почему более длинные конвейеры делают один интервал задержки недостаточным? - PullRequest
3 голосов
/ 24 мая 2019

Я прочитал следующее утверждение в учебнике «Организация и дизайн компьютеров» «Компьютерная организация и дизайн» Patterson & Hennessy:

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

Я могу понять, почему «выдача нескольких инструкций за такт» может сделать недостаточным один интервал задержки, но я не знаю, почему «дольше»конвейеры "вызывают это.

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

1 Ответ

5 голосов
/ 24 мая 2019

Если вы добавите какие-либо этапы перед этапом, который обнаруживает ветви (и оценивает принятые / не принятые для условных переходов), 1 интервал задержки больше не скрывает «задержку» между переходами, входящими в первый этап. конвейера и правильный адрес счетчика программы после известная ветвь.

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

1 интервал задержки достаточен только в MIPS, потому что условия ветвления оцениваются на этапе ID, перед обычным этапом EX. (Оригинальный MIPS - это классический 5-ступенчатый RISC: IF ID EX MEM WB.) Более подробную информацию см. В статье Википедии о классическом конвейере RISC , в частности, в разделе Управление опасностями .


Вот почему MIPS ограничивается простыми условиями, такими как beq (поиск любых несоответствий в XOR) или bltz (проверка битов знака). Он не может делать ничего, что требует сумматора для переноса переноса (поэтому общая blt между двумя регистрами - только псевдоинструкция ).

Это очень ограничительно: более длинный интерфейс может поглотить задержку из большего / более ассоциативного кэша команд L1 и зарегистрировать выборку +, оценивая состояние ветвления все в том же цикле, что и декодирование, вероятно, довольно ограничено по времени.

Повышение тактовой частоты или даже просто обнаружение опасностей данных (в отличие от оригинального MIPS), вероятно, потребует добавления другого этапа или, возможно, переноса оценки ветвления в EX.

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


Но вместо того, чтобы вводить больше задержки ветвления слотов , чтобы скрыть эту задержку ветвления, реальное решение - ветвь предсказание .

...