Нужно перезагрузить буфер в спекулятивном исполнении?

Я понимаю необходимость буфера повторного заказа в спекулятивном исполнении. Однако, учитывая последовательность неспекулятивных инструкций без каких-либо ветвей, почему все эти инструкции все равно должны проходить через ROB и затем совершать в порядке? Поскольку нет опасности управления и при условии наличия переименования регистров во избежание опасностей WAR и WAW, является ли необходимость использования ROB в таком случае?Нужно перезагрузить буфер в спекулятивном исполнении?

Одна из причин, о которых я мог думать, заключается в обработке неточных исключений. Есть ли другая причина?

источник

2013-12-13 appusajeev

Что вы подразумеваете под «неспекулятивными инструкциями»? Если у вас есть исполнение вне порядка, все будет спекулятивным до выхода на пенсию. Даже если нет ветки - как бы вы откатились от ошибок, прерываний и т. Д.? По той же причине вам необходимо, чтобы ROB восстановил порядок программы при фиксации. – Leeor

Не спекулятивными инструкциями я имел в виду инструкции, которые не были вызваны спекулятивно (инструкции не выбраны предсказанием ветвления, но выбраны в обычном порядке программы), так что из-за неправильной записи значений результата не возникает никаких проблем. И да, исключения - одна из причин, по которым нам нужен ROB в любом случае. Интересно, была ли другая причина. – appusajeev

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

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

Еще одна «польза» от необходимости проходить через ROB - это переименование регистра. Без упорядоченного индекса вам будет сложно управлять вашими физическими регистрами, чтобы иметь смысл в соответствии с порядком выполнения программы. Скажем, у вас есть 3 последовательных инструкций, как например:

inc rax 
add rbx, rax ; assume rbx is the dest 
inc rax

Say rbx готов поздно, когда он, наконец, готов выполнить add, как бы испорченный двигатель знать, какое значение rax взять? у вас есть старая стоимость, +1 и +2, и все они готовы - машина ООО должна отметить источник как переименованную версию rax на момент добавления в ROB. Кстати, есть и другие способы достижения этой корректности, но они сложнее и требуют очередей заказов.

источник

2013-12-30 07:44:24 Leeor

Можно было переименовать только с ROB, не так ли? – appusajeev

@appusajeev, ROB является очередью, вам также, как правило, также потребуется таблица поиска, чтобы перевести логические в имена физических регистров - например, RAT (таблица псевдонимов регистров) в терминах P6. Тем не менее, есть некоторые проекты, которые принципиально разные, такие как процессоры обработки данных, которые поддерживают распределенные очереди, которые устраняют необходимость поиска в регистре. На самом деле они не делают ООО, хотя некоторые утверждают, что они эквивалентны. – Leeor

Я имею в виду, что, имея идентификатор ROB в качестве источника и назначения инструкций, можно было бы правильно использовать файлы физического регистра? – appusajeev

Нужно перезагрузить буфер в спекулятивном исполнении?

ответ

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