В соответствии с https://en.wikipedia.org/wiki/Classic_RISC_pipeline#Control_hazards, классический MIPS разрешает ответвления на этапе ID , а слот задержки ответвления полностью скрывает входной пузырь. (Предполагая, что компилятор может заполнить его чем-то другим, кроме NOP).
Даже если это не так и ветке нужно было ждать разрешения EX , ЦП может умозрительно получить и декодировать более поздние инструкции; Ни один из них не достигает MEM или WB до того, как будет обнаружено правильное направление ветвления, поэтому они не оказывают постоянного влияния на архитектурное состояние. (На самом деле ни один из них даже не достиг EX, поэтому вообще нет спекулятивного выполнения, только спекулятивное декодирование).
Если EX обнаружит, что ветвление должно быть занято, конвейер должен будет перезапустить извлечение команды sw без jr в канале. (add остается, потому что он находится в слоте с задержкой перехода: он выполняется в обоих случаях.)
Дальнейшее чтение: разница между спекуляциями и предсказаниями , а также этот неясный вопрос Неупорядоченное исполнение по сравнению со спекулятивным выполнением . Хороший ответ Хади охватывает ряд вещей, которые могут делать процессоры, прежде чем они будут уверены, в какую сторону идет ветка.
Простая выборка и декодирование инструкций, основанных на предсказании ветвлений, но не выполнение их, является одним из самых простых, и многие люди вообще не считают его спекулятивным исполнением . До сих пор существует предположение, что требуется конвейерная очистка / переадресация, в отличие от останова до тех пор, пока не будет точно известен правильный адрес выборки. (Без интервала задержки ветвления вы не могли бы даже обнаружить ветвь (в декодировании), пока вы уже не получили инструкцию с потенциально неправильного пути. В более глубоких и широких конвейерах предсказание ветвления важно для предсказания следующего блока выборки адрес еще до того, как декодирование выяснилось, есть ли , * какие-либо ветви в текущем блоке. Это отдельно от детального предсказания, куда идет конкретная инструкция перехода.)
Странная вещь на этой диаграмме в том, что она показывает jr и sw на одной и той же стадии в одном и том же цикле . Это не имеет смысла, и sw не может остановиться, пока fetch не достигнет его.
Это для случая взятой ветки? Это также не имеет смысла, потому что тогда jr вообще не должно быть в конвейере. И sw не может остановиться в том же цикле, где add находится в стадии извлечения.