Процессор, по-видимому, отбрасывает содержимое ROB, возвращаясь к последнему состоянию отключения, прежде чем обслуживать прерывание.
Пропадание ветки в полете не меняет этого.В зависимости от ЦП (более старого / более простого) он, возможно, уже находился в процессе отката в исходное состояние и сбрасывался из-за пропадания ветви, когда пришло прерывание.
Как говорит @Hadi, ЦПв этот момент можно было выбрать выход из ветви (с прерыванием, нажимающим CS: RIP, указывающим на правильную цель перехода), вместо того, чтобы оставить его для повторного выполнения после возврата из прерывания.
Но это толькоработает, если инструкция ветки уже была готова к удалению: не было никаких инструкций старше, чем ветвь, все еще не выполненная.Поскольку важно обнаруживать пропуски в ветвях как можно раньше, я предполагаю, что восстановление веток начинается, когда во время выполнения обнаруживается ошибочный прогноз, а не в ожидании выхода на пенсию.(Это не похоже на другие виды сбоев: например, Meltdown и L1TF основаны на сбойной нагрузке , а не , запускающей #PF обработку сбоев до тех пор, пока она не выйдет на пенсию, поэтому процессор уверен, что действительноошибка на истинном пути выполнения. Вы не хотите запускать дорогостоящий сброс конвейера до тех пор, пока не убедитесь, что он не находится в тени ошибочного прогноза или более ранней ошибки.)
Но так как ветвление отсутствуетне делайте исключений, перенаправление внешнего интерфейса может начаться раньше, чем мы уверены, что инструкция перехода является частью правильного пути.
например, cmp [cache_miss_load], 123 / jeq неверно предсказываетно не будет обнаружен в течение длительного времени.Затем, в тени этого неверного прогноза, cmp eax, 1 / je на «неправильном» пути запускается и для него обнаруживается неправильный прогноз.При быстром восстановлении прошедшие операции сбрасываются, и извлечение / декодирование / выполнение с «правильного» пути может начаться до того, как будет обнаружен ранее ошибочный прогноз.
Чтобы поддерживать низкую задержку IRQ, ЦП некак правило, дают инструкции в полете дополнительное время для выхода на пенсию.Кроме того, любые удаленные хранилища, которые все еще хранят свои данные в буфере хранилища (еще не переданные в L1d), должны зафиксировать, прежде чем любые хранилища обработчиком прерывания смогут зафиксировать.Но прерывания сериализуются (я думаю), и любой MMIO или port-IO в обработчике, вероятно, будет включать в себя барьер памяти или строго упорядоченное хранилище, поэтому допущение удаления большего количества инструкций может повредить задержке IRQ, если они связаны с хранилищами.(После того, как магазин закрывается, это, безусловно, должно произойти, даже если его данные все еще находятся в буфере хранилища).
Неупорядоченный сервер всегда знает, как откатиться до заведомо хорошего пенсионного состояния;все содержимое ROB всегда считается спекулятивным, потому что любая загрузка или хранилище может дать сбой, как и многие другие инструкции 1 . Предположение о ветвях не суперспециальное.
Ветви отличаются только тем, что имеют дополнительное отслеживание для быстрого восстановления (буфер порядка ветвлений в Nehalem и новее), потому что они ожидают , чтобы неправильно прогнозировать их с частотой, не пренебрежимо малой во время нормальной работы.См. Что именно происходит, когда процессор Skylake неправильно предсказывает ветвь? для некоторых деталей.Особенно цитата Дэвида Кантера:
Нехалем улучшил восстановление от неправильных предсказаний ветвей, которые были перенесены в Песчаный Мост.Как только ошибочное предсказание ветви обнаружено, ядро может возобновить декодирование, как только будет известен правильный путь, в то же время, когда машина, вышедшая из строя, очищает мопы от неверно спекулированного пути.Ранее декодирование не возобновлялось до тех пор, пока конвейер не был полностью очищен.
(Этот ответ намеренно очень ориентирован на Intel, потому что вы пометили его intel , а не x86 . Я предполагаю, что AMD делает что-то похожее, и, вероятно, большинство не в порядке длядругие ISA в целом схожи. За исключением того, что неправильное предположение о порядке следования памяти не имеет значения для процессоров с более слабой моделью памяти, где процессорам разрешено визуально изменять порядок загрузки.)
Сноска 1: Так можноdiv или любая инструкция FPU, если исключения FP не маскируются.А для ненормального результата FP может потребоваться помощь микрокода, даже если исключения FP замаскированы так, как они есть по умолчанию.
В процессорах Intel неправильное предположение порядка памяти может также привести к возникновению ядерного конвейера (загрузкаспекулятивно сделано рано, до завершения более ранних загрузок, но кэш потерял свою копию строки, прежде чем модель памяти x86 заявила, что нагрузка может принять свое значение).