Когда происходит прерывание, что происходит с инструкциями в конвейере?

Ответ 1

Во-первых, терминология:

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

В терминологии Intel исключение - это что-то, вызванное выполнением инструкций на процессоре. Например. ошибка страницы или ловушка команды undefined.

--- + Прерывания сбрасывают все инструкции в полете

На каждой машине, с которой я знаком - например, все процессоры Intel с тех пор, как P5 (я работал на P6), AMD x86s, ARM, MIPS - при получении сигнала прерывания инструкции в конвейере почти всегда покраснели, выброшены.

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

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

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

В простых машинах логика прерываний обычно находится на последней стадии конвейера, WB, что примерно соответствует фиксации перехвата передовых машин. Иногда он перемещается до пикапа непосредственно перед этим, например, MEM в вашем примере. Таким образом, на таких машинах все команды в IF ID EX и обычно MEM удаляются.

--- ++ Почему я забочусь: избегайте отработанной работы

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

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

например. если вы берете прерывание, но если одна из инструкций, уже находящихся в полете, также принимает исключение, после того, как вы восстановили IF (выбор команды), но до того, как какая-либо инструкция в прерывании совершила, что имеет приоритет? A: Это зависит. И такая вещь - боль, с которой приходится иметь дело.

--- +++ Фольклор: пакетное прерывание ОС OS

Это похоже на то, как некоторые операционные системы IBM с мейнфреймом работают:

• со всеми прерываниями, заблокированными при нормальной работе, за исключением прерывания таймера;
• в прерывании таймера, вы разблокируете прерывания и обрабатываете их все;
• а затем вернуться к нормальной работе с заблокированным режимом прерываний

Предположительно, они могут использовать только такой режим "прерывания пакетной обработки" при интенсивной загрузке; если они слегка загружены, они могут не блокировать прерывания.

--- +++ Отложенные проверки на проверку машины

Идея отсрочить прерывания, чтобы дать инструкции, которые уже есть в конвейере, возможность выполнить, также похожа на то, что я называю Exferred Machine Check Exception - концепцией, которую я включил в первоначальную архитектуру проверки компьютеров Intel P6, примерно в 1991 году, 1996, но который, похоже, не был выпущен.

Здесь могут возникать ошибки проверки: ошибки проверки, такие как (un) исправляемые ошибки ECC ПОСЛЕ ПОДАЧИ инструкции (то есть после того, как предположительно младшие команды зафиксировали состояние, например, записанные регистры), или до того, как команда удалилась.

Классический пример ошибок AFTER - это нескорректируемый ECC, запускаемый магазином, который помещается в буфер записи при градуировке. Практически все современные машины делают это, все машины с TSO, что в значительной степени означает, что всегда существует вероятность неточной ошибки проверки машины, которая могла бы быть точной, если бы вы достаточно заботились о том, чтобы не хранить буферы.

Классический пример ошибок BEFORE - это... ну, каждая инструкция, на любой машине с конвейером. Но что более интересно, ошибки в инструкциях неправильного пути, в тени неправильного предсказания ветки.

Когда инструкция загрузки получает некорректируемую ошибку ECC, у вас есть два варианта:

(1) вы можете немедленно вытащить цепочку, убив не только инструкции YOUNGER, чем инструкцию по загрузке, но и любые инструкции OLDER

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

(3) Но что, если инструкция загрузки, которая получила некорректируемую ошибку ECC, была неправильной инструкцией пути и никогда не удаляется, потому что более ранняя ветвь inflight неверно предсказана и идет другим путем?

Хорошо, вы могли бы написать статус, чтобы попытаться сделать его точным. У вас должны быть счетчики точных ошибок и неточные ошибки. В противном случае вы могли бы игнорировать ошибку в такой команде неправильного пути - в конце концов, если это жесткая ошибка, она будет либо затронута снова, либо может быть не так./Например. возможно, что ошибка будет архитектурно беззвучной - например, строка плохого кэша может быть перезаписана хорошей линией кэша для того же адреса.

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

Такая ошибка не будет возникать на счетчике программы, связанном с инструкцией, вызвавшей ошибку, но может по-прежнему иметь точное состояние.

Я вызываю (2) отсрочку исключения проверки машины; (3) - это то, как вы можете справиться с отсрочкой.

IIRC, все ошибки проверки машины Intel P6 были неточными.

--- ++ На захватной руке: еще быстрее

Итак, мы обсудили

0), немедленно прерывая прерывание, или, если прерывания заблокированы, выполнение инструкций и микрокоманд до тех пор, пока не будет достигнута разблокированная точка прерывания. А затем промойте все инструкции в полете.

1) пытается выполнить инструкции в конвейере, чтобы избежать потраченной впустую работы.

Но есть и третья возможность:

-1), если у вас есть контрольные точки состояния микроархитектуры, немедленно выполните прерывание, не дожидаясь разблокировки прерывания. Это можно сделать только в том случае, если у вас есть контрольная точка всего релевантного состояния в самой последней точке "безопасный для прерывания".

Это еще быстрее, чем 0), поэтому я обозначил его -1). Но для этого требуются контрольные точки, которые используют многие, но не все агрессивные процессоры - например, Intel P6 не использует контрольные точки. И такие контрольно-пропускные пункты после выхода на пенсию становятся фанковыми в присутствии общей памяти - в конце концов, вы можете выполнять операции с памятью, такие как нагрузки и хранилища, в то время как прерывания блокируются. И вы можете даже общаться между процессорами. Обычно аппаратная транзакционная память этого не делает.

--- + Исключения помечены инструкциями, затронутыми

И наоборот, исключения, такие как ошибки страниц, отмечают затронутую команду.

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

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

--- + "Прерывания программного обеспечения"

"Программные прерывания" - это команда с неправильным названием, обычно связанная с системными вызовами.

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

Однако, все машины, с которыми я знаком, сериализуются в некотором роде. На моем языке они не переименовывают уровень привилегий.

--- + "Точные прерывания", EMON, PEBS

В другом плакате указаны точные прерывания.

Это исторический термин. На большинстве современных машин прерывания определяются точно. Старые машины с неточными прерываниями не были очень успешными на рынке.

Однако есть альтернативный смысл, я был вовлечен в введение: когда я получил Intel, чтобы добавить возможность создавать прерывание при переполнении счетчика производительности, сначала используя внешнее оборудование, а затем внутри ЦП, это было в первые несколько поколений, совершенно неточные.

например. вы можете установить счетчик для подсчета количества отложенных инструкций. Логика выхода на пенсию (RL) увидит, что инструкции уходят в отставку, и сигнализирует схему мониторинга событий производительности (EMON). Для отправки этого сигнала от RL до EMON может потребоваться два или три тактовых цикла. EMON увеличит счетчик, а затем увидит, что произошло переполнение. Переполнение вызовет запрос прерывания на APIC (Advanced Programmable Interrupt Controller). APIC может занять несколько циклов чтобы выяснить, что происходит, а затем указать логику выхода на пенсию.

т.е. прерывание EMON будет сигнализировано неточно. Не во время мероприятия, а спустя некоторое время.

Почему эта неточность? Ну, в 1992-6, оборудование для измерения производительности не было высоким приоритетом. Мы использовали существующие аппаратные прерывания. Нищие не могут быть выбраны.

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

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

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

Теперь вы можете сделать событие производительности точным, рассматривая его как ловушку. Например. если это событие, подобное инструкциям, ушло в отставку, вы можете немедленно отключить ловушку логики выхода на пенсию, вместо того, чтобы использовать этот замкнутый цикл, описанный выше. Если это происходит раньше в конвейере, вы можете иметь тот факт, что он произошел, отмеченный в статусе сбоя инструкции в ROB (буфере повторного заказа). Что-то вроде этого - это то, что сделала Intel с помощью PEBS (Precise Event Based Sampling). http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf.

Однако обратите внимание, что не все события могут быть отобраны с использованием PEBS. Например, PEBS в приведенном выше примере может подсчитывать нагрузки, в которых произошел сбой или промах кэша, но не хранится (поскольку магазины появляются позже).

Таким образом, это похоже на исключения: событие доставляется только тогда, когда команда удаляется. Потому что в каком-то смысле событие не произошло полностью - это инструкция загрузки, которая пропускает кеш, а затем удаляется. И инструкции после отмеченной команды PEBS сбрасываются из конвейера.

Я надеюсь --- + Позднее дополнение о ранних компьютерах

Ответ 2

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

Обработка синхронных прерываний немного отличается. Принимая x86 в качестве примера, синхронные исключения бывают трех вариантов: ловушек, ошибок и прерываний.

Ловушка, такая как INT3, заставляет ядро ​​нажимать команду после ловушки в стеке, так что когда ISR возвращается, ядро ​​не бессмысленно повторно выполняет ту же самую команду захвата.

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

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

Содержимое фрейма стека прерываний, заданного ядром, перед входом в ISR различается в зависимости от того, в каком случае вы говорите.