Когда конвейер выполняет 2 этапа декодирования, когда есть зависимость RAW в 2 последовательных инструкциях - PullRequest
Новая
       122

Когда конвейер выполняет 2 этапа декодирования, когда есть зависимость RAW в 2 последовательных инструкциях

0 голосов
/ 02 февраля 2020

Рассмотрим конвейер RIS C, имеющий 5 этапов. Определите, сколько циклов требуется для инструкции, приведенной ниже, предположите пересылку операнда, используется прогнозирование ветвления, при котором переход не берется, ACS - это инструкция ветвления, а пять - Этапы: извлечение инструкций, декодирование, выполнение, память и обратная запись. 

I1: ACS R0, R1,X

I2: LOAD R2, 0(R3)

I3: SUB R4 R2, R2
I4: X: ADD R5, R1, R2
I5: LOAD R1, 0(R5)

I6: SUB R1, R1, R4
I7: ADD R1, R1, R5 

A. 11
B. 12
C. 13
D. 14

Решение: Solution

В решении я не могу понять, почему пренебрегли ли они двумя циклами ДЕКОД в I6 и I7, хотя они имеют зависимость от RAW?

Источник вопроса: Вопрос 41 из https://practice.geeksforgeeks.org/contest-quiz/sudo-gate-2020-mock-iii

1 Ответ

2 голосов
/ 02 февраля 2020

Я думаю, что ответ дает правильную сумму (13 циклов), но ставит в стойло неправильную инструкцию .

I5 не нужно останавливаться; I4 (ADD R5, R1, R2) производит R5 вовремя, чтобы переслать его в EX следующей инструкции для вычисления адреса (LOAD R1, 0(R5)). (Ваш 5-ступенчатый конвейер classi c RIS C имеет обходную переадресацию).

Но I6 читает результат инструкции загрузки, и загрузки выдают свой результат на цикл позже, чем АЛУ в EX. Так же, как и I3, I6 должен блокироваться, а не I5.

(I7 зависит от I6, но I6 - это инструкция ALU, поэтому он может пересылаться без остановки).

Они останавливаются на этапе D, потому что этап ID не может получить регистры, которые нагрузка I2 / I5 еще не произвела.

Отдельно от этого ваша диаграмма показывает I4 (и что должно быть I7) даже не извлекается, когда предыдущая инструкция останавливается. Это не имеет смысла для меня. В начале этого цикла конвейер даже не знает, что ему нужно остановить, потому что он еще не декодировал I3 (и I6) и обнаружил, что он читает регистр неготовности, поэтому необходима блокировка.

Fetch не ждет, пока после декодирования предыдущей инструкции не будет установлено, остановилась она или нет; это победило бы всю цель конвейерной обработки. Это должно выглядеть так: 

I3     IF   D   D  EX  MEM   WB
I4         IF  IF   D   EX  MEM  WB

Кстати, задержка загрузки является причиной того, что classi c MIPS имеет слот задержки загрузки (непредсказуемое поведение, если вы попытаетесь использовать регистр в следующей инструкции после загрузка в него). Позже MIPS добавил блокировки для остановки, если вы сделаете это, вместо того, чтобы сделать это ошибкой, так что вы можете сохранить stati c code-size меньшим (без заполнителя NOP) в тех случаях, когда вы не можете найти какую-либо другую инструкцию для вставки в нее. слот. (А некоторые даже позже MIPS сделали exe-out exe c, который может скрывать задержки.)

...