2016-04-05 3 views
2

Это теоретический вопрос, и я чувствую себя застрявшим. Предположим, что я беру ARM ISA и конвейерный datapath. Я использую предиктор ветки, который для простоты всегда предсказывает, что ветвь берется. Как видно, он работает, если отрасль действительно должна быть взята, но не работает иначе. Если он терпит неудачу, он должен откат и отменить все изменения, т. Е. Выполнить промывку трубопровода.Как очистить трубопровод?

Как это должно быть сделано?

Что делать, если какое-либо значение записывается в какой-либо регистр?

Тогда как я могу вернуть этот регистр в его предыдущее значение? То же самое касается флагов?

+1

Связано: [Происходит ли неверное предсказание ветвления весь конвейер, даже для очень короткого тела if-statement?] (Https://stackoverflow.com/questions/29522431/does-a-branch-misprediction-flush-the- все трубопроводный даже в обмен на сверхкраткосрочный-если-е). Как обсуждалось в комментариях, один простой способ промывки - дождаться выхода из строя ошибочной ветви; то в состоянии регистрации есть правильное состояние в заказе, к которому вы можете вернуться назад. В противном случае вы проверяете состояние переименования регистров для быстрого восстановления от неправильных прогнозов (быстрее, чем полный флеш, например, для исключений). –

+1

Без какого-либо механизма отката/восстановления (обычно с переименованием регистра) вы не можете выполнять спекулятивное исполнение вне порядка. ** Вы можете извлекать/декодировать на основе предсказания ветвления без какой-либо специальной поддержки **, но вы не можете позволить какой-либо спекулятивной инструкции модифицировать единственную копию архитектурного состояния. (как указывает ответ Дрика, конвейер в заказе может давать инструкции до этапа обратной записи. Поскольку он находится в порядке, мы уже знаем, что предыдущая инструкция не была ошибочной или неверно предсказана). –

ответ

2

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

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

В более сложных процессорах, более длинных трубопроводах и испорченных ядрах, то техник, которая используется обычно использует переименование регистров:

https://en.wikipedia.org/wiki/Register_renaming

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

Смежные вопросы