Во-первых, терминология:
Обычно, в Intel, по крайней мере, прерывание является то, что приходит от внешнего мира. Обычно он не синхронизируется с инструкциями, выполняемыми на процессоре, то есть является асинхронным внешним прерыванием.
В терминологии Intel исключение вызвано выполнением инструкций на процессоре. Например. ошибка страницы или неопределенная ловушка команд.
--- + Прерывания вровень все инструкции в полете
На каждой машине, что я знаком с - например, все процессоры Intel с тех пор, как P5 (я работал на P6), AMD x86s, ARM, MIPS - при получении сигнала прерывания инструкции в конвейере почти всегда покраснели, выброшены.
Единственная причина, по которой я говорю «почти всегда», это то, что на некоторых из этих машин вы не всегда находитесь в том месте, где вам разрешено получать прерывание. Итак, вы переходите к следующему месту, где разрешено прерывание - любая граница инструкции, как правило, - и THEN отбрасывают все инструкции в конвейере.
В этом случае прерывания могут быть заблокированы. Итак, вы продолжаете до тех пор, пока прерывания не разблокируются, и ТОГДА вы их выбросите.
Теперь эти машины не являются точными простыми 5-ступенчатыми трубопроводами. Тем не менее, это наблюдение - то, что большинство машин выбрасывают все инструкции в трубопроводе, в пипетках до пипец, где живет логика прерываний, остается практически повсеместно.
В простых машинах логика прерывания обычно находится на последней стадии трубопровода, WB, что примерно соответствует фиксации перегруженных машин. Иногда он перемещается до пикапа непосредственно перед этим, например, MEM в вашем примере. Таким образом, на таких машинах все инструкции в IF ID EX и, как правило, MEM, удаляются.
--- ++ Почему я забочусь: избегание Wasted Работа
Эта тема близка и дорога моему сердцу, потому что я предложил не делать этого. Например. при посещении клиентов, пока мы планировали построить P6, я попросил клиентов, которых они предпочли, - более низкие задержки прерывания, инструкции по промывке, которые находятся в полете, или (немного) более высокую пропускную способность, позволяя по крайней мере выполнить некоторые из инструкций в полете по стоимость немного большей задержки.
Однако, хотя некоторые клиенты предпочли последнее, мы решили сделать традиционную вещь, немедленно промывшуюся. Помимо более низкой задержки, основной причиной является сложность:
E.g. если вы берете прерывание, но если одна из инструкций, уже находящихся в полете, также принимает исключение, после того, как вы восстановили IF (выбор команды), но до того, как какая-либо инструкция в прерывании совершила, что имеет приоритет? A: Это зависит. И такая вещь - боль, с которой приходится иметь дело.
--- +++ Фольклор: мэйнфреймов OS Interrupt Дозирование
Это скорее походит так, что некоторые универсальные операционные системы IBM, как сообщается, работали:
- со всеми прерываниями блокированных в нормальном режиме работы кроме прерывания таймера;
- в прерывании таймера, вы разблокируете прерывания и обрабатываете их все;
- , а затем вернуть в нормальный режим работы с прерываниями заблокированного состоянием
Предположительно они могли бы использовать только такой режим «Прерывание дозирования», когда сильно загружен; если они слегка загружены, они не могут блокировать прерывания.
--- +++ Отложенный машина Проверить Исключения
Идея откладывая прерывания, чтобы дать инструкции уже в трубопроводе шанс выполнить также подобно тому, что я называю Отложенный Machine Check Exception - это понятие, Я включил в оригинальную семейную архитектуру проверки ПК Intel P6 около 1991-1996 годов, но, похоже, не был выпущен.
Вот что вы можете проверить: ошибки проверки машины, такие как (un), могут возникнуть ошибки ECC ПОСЛЕ ПОДАЧИ инструкции (то есть после того, как предположительно младшие инструкции зафиксировали состояние, например, записанные регистры), или до того, как инструкция ушла в отставку.
Классический пример ошибок AFTER - это нескорректируемый ECC, запускаемый магазином, который помещается в буфер записи при градуировке. Практически все современные машины делают это, все машины с TSO, что в значительной степени означает, что всегда существует вероятность неточной ошибки проверки машины, которая могла бы быть точной, если бы вы заботились о том, чтобы не хранить буфер.
Классический пример ошибок BEFORE ... ну, каждая инструкция, на любой машине с конвейером. Но более интересно, ошибки в неверных инструкциях, в тени неправильного предсказания ветви.
Когда команда загрузки получает неисправимую ошибку ECC, у вас есть два варианта:
(1) можно сразу вытащить цепочку, убивая не только инструкцию Моложе инструкции нагрузки, но и любые ПОЖИЛЫХ инструкции
(2), или вы можете написать какой-то код статуса в логику, которая контролирует спекуляцию, и принять исключение при выходе на пенсию. Это в значительной степени то, что вам нужно сделать для ошибки страницы, и делает такие ошибки точными, помогая отлаживать.
(3) Но что, если инструкция по загрузке, которая получила неуправляемую ошибку ECC, была неправильной инструкцией по пути и никогда не удаляется, потому что более поздняя ветвь рассеяния неверно предсказана и пошла другим путем?
Ну, вы можете написать статус, чтобы попытаться сделать его точным. У вас должны быть счетчики точных ошибок и неточные ошибки. В противном случае вы могли бы игнорировать ошибку в такой команде неправильного пути - в конце концов, если это жесткая ошибка, она будет либо затронута снова, либо может быть не так./Например. возможно, что ошибка будет архитектурно беззвучной - например, строка плохого кэша может быть перезаписана хорошей линией кэша для одного и того же адреса.
И если вы действительно этого хотели, вы могли бы установить немного, чтобы, если старшая ветвь неверно предсказана, вы берете исключение проверки машины в этот момент времени.
Такая ошибка не будет возникать на счетчике программы, связанном с инструкцией, вызвавшей ошибку, но может по-прежнему иметь точное состояние.
Я звоню (2) отложено исключение проверки машины; (3) - это то, как вы можете справиться с отсрочкой.
IIRC, все ошибки проверки машины Intel P6 были неточными.
--- ++ С зажимающей рукой: еще быстрее
Итак, мы обсудили
0) принимая прерывание немедленно, или, если прерывания, не выполнение инструкций и микрокоманды до прерывания разблокирована точка. А затем промойте все инструкции в полете.
1) пытается выполнить инструкции в трубопроводе, чтобы избежать расточительной работы.
Но есть третья возможность:
-1), если у вас есть микроархитектуры государственных контрольно-пропускные пункты, принять прерывание немедленно, никогда не ожидая прерывания разблокированной точки. Это можно сделать только в том случае, если у вас есть контрольная точка всего релевантного состояния в самой последней точке «безопасный для прерывания».
Это даже быстрее, чем 0), поэтому я обозначил его как -1). Но для этого требуются контрольные точки, которые используют многие, но не все агрессивные процессоры - например, Intel P6 не использует контрольные точки. И такие контрольно-пропускные пункты после выхода на пенсию становятся фанковыми в присутствии общей памяти - в конце концов, вы можете выполнять операции с памятью, такие как нагрузки и хранилища, в то время как прерывания блокируются. И вы можете даже общаться между процессорами. Обычно аппаратная транзакционная память этого не делает.
--- + Исключения маркировать инструкции влияют
И наоборот, исключение, такие вещи, как страничные ошибки, отметьте команду пострадавших.
Когда эта инструкция собирается совершить, в этот момент все последующие инструкции после исключения очищаются, а перенаправление команды перенаправляется.
Предположительно, выбор команды может быть восстановлен ранее, так как на большинстве процессоров уже обрабатываются неверные предсказания ветвления, в момент, когда мы знаем, что произойдет исключение. Я не знаю, кто это делает. При текущих нагрузках исключения не так важны.
--- + «Программное обеспечение Прерывание»
«Программное обеспечение прерываний» является неправильно именованной инструкцией, как правило, связан с системными вызовами.
Возможно, такую инструкцию можно было бы обработать без прерывания трубопровода, предсказанного как ветка.
Однако все машины, с которыми я знаком, сериализуются в некотором роде. На моем языке они не переименовывают уровень привилегий.
--- + "Точные Прерывания", EMON, УИБ
Другой плакат упомянул точные прерывания.
Это исторический термин. На большинстве современных машин прерывания определяются точно. Старые машины с неточными прерываниями не были очень успешными на рынке.
Однако, есть альтернативное значение, я был вовлечен в введение: когда я получил возможность добавить Intel к прерыванию при переполнении счетчика производительности, сначала используя внешнее оборудование, а затем внутри ЦП, оно было в первые несколько поколений, совершенно неточны.
E.g. вы можете установить счетчик для подсчета количества отложенных инструкций. Логика выхода на пенсию (RL) увидит, что инструкции уходят в отставку, и сигнализирует схему мониторинга событий производительности (EMON). Для отправки этого сигнала от RL до EMON может потребоваться два или три тактовых цикла. EMON увеличит счетчик, а затем увидит, что произошло переполнение. Переполнение вызовет запрос прерывания на APIC (Advanced Programmable Interrupt Controller). APIC может занять несколько циклов , чтобы выяснить, что происходит, а затем сигнализировать о выходе на пенсию.
I.e. прерывание EMON будет сигнализировано неточно. Не во время мероприятия, а через некоторое время.
Почему эта неточность? Ну, в 1992-6, оборудование для измерения производительности не было высоким приоритетом. Мы использовали существующие аппаратные прерывания. Нищие не могут быть выборами.
Но, кроме того, некоторые характеристики являются внутренне неточными. Например. когда вы сигнализируете прерывание для промаха в кеше на спекулятивной инструкции, которая никогда не удаляется? (У меня есть схема, которую я называл событиями с отсрочкой EMON, но это все равно считается слишком дорогостоящим.) В этом отношении, что касается кэша, промахивается в инструкциях магазина, где хранилище помещается в буфер хранилища, а инструкция уже удалена?
I.e. иногда события производительности происходят после того, как команда, с которой они связаны, совершила (отставку). Иногда раньше. И часто не совсем в инструкции, с которой они связаны.
Но во всех реализациях до сих пор, насколько я знаю, эти события производительности обрабатываются как прерывания: существующие инструкции в трубе очищаются.
Теперь вы можете сделать точное исполнение, рассматривая его как ловушку. Например. если это событие, подобное инструкциям, ушло в отставку, вы можете немедленно отключить ловушку логики выхода на пенсию, вместо того, чтобы использовать этот замкнутый цикл, описанный выше. Если это происходит раньше в конвейере, вы можете иметь тот факт, что он произошел, отмеченный в статусе сбоя инструкции в ROB (буфере повторного заказа). Что-то вроде этого - это то, что сделала Intel с помощью PEBS (Precise Event Based Sampling). http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf.
Однако обратите внимание, что не все события могут быть выбраны с использованием PEBS. Например, PEBS в приведенном выше примере может подсчитывать нагрузки, в которых произошел сбой или промах кэша, но не хранится (поскольку магазины появляются позже).
Так что это как исключения: событие доставляется только в том случае, когда инструкция уходит в отставку. Потому что в каком-то смысле событие не произошло полностью - это инструкция загрузки, которая пропускает кеш, а затем уходит. И инструкции после отмеченной инструкции PEBS сбрасываются из конвейера.
Надеюсь, что --- + Позднее дополнение о ранних компьютерах
Трубопроводы смываются во многом так же, как и для, например, неверно предсказанная ветка - точные детали зависят от того, о каком процессоре вы говорите. –
Я думаю, что жаль, что вопрос был проголосован -1. На самом деле это довольно фундаментальный вопрос в компьютерной (микро) архитектуре, который часто неправильно понимается, как показывает первый смущенный ответ. –