Во-первых, терминология:
Обычно, по крайней мере, у Intel прерывание - это то, что исходит из внешнего мира.Обычно оно не синхронизировано с инструкциями, выполняемыми на процессоре, то есть это асинхронное внешнее прерывание.
В терминологии Intel исключение - это то, что вызвано выполнением инструкций на процессоре.Например, ошибка страницы или неопределенная ловушка инструкций.
--- + Прерывания сбрасывают все команды в полете
На каждой машине, с которой я знаком - например, на всех процессорах Intel начиная с P5 (Я работал над P6), AMD x86s, ARM, MIPS - когда сигнал прерывания получен, инструкции в конвейере почти всегда сбрасываются, выбрасываются.
Единственная причина, по которой я говорю «почти всегда», заключается в том, чтона некоторых из этих машин вы не всегда находитесь в месте, где вам разрешено получать прерывания.Итак, вы переходите к следующему месту, где разрешено прерывание - обычно к любой границе инструкций - и ТО отбрасываете все инструкции в конвейере.
В этом отношении прерывания могут быть заблокированы.Таким образом, вы продолжаете до тех пор, пока прерывания не будут разблокированы, и затем вы их выбрасываете.
Теперь эти машины не совсем простые 5-этапные конвейеры.Тем не менее, это наблюдение - что большинство машин отбрасывают все инструкции в конвейере, в трубопроводах перед конвейером, где живет логика прерывания - остается почти универсально верным.
В простых машинах логика прерываний обычно живет на последней стадиииз конвейера, WB, примерно соответствует совершить этап передовых машин.Иногда он поднимается до конвейера, например, MEM в вашем примере.Итак, на таких машинах все инструкции в IF ID EX и, как правило, MEM отбрасываются.
--- ++ Почему я забочусь: как избежать ненужной работы
Эта тема близка идорогой моему сердцу, потому что я предложил НЕ делать этого.Например, во время визитов клиентов, когда мы планировали построить P6, я спросил клиентов, что они предпочитают: прерывания с более низкой задержкой, инструкции по очистке, которые находятся в полете, или (немного) более высокая пропускная способность, позволяющая выполнить хотя бы некоторые инструкции в полете,ценой чуть более длинной задержки.
Однако, хотя некоторые клиенты предпочли последнее, мы решили сделать традиционную вещь, немедленно сбрасывая.Помимо более низкой задержки, основной причиной является сложность:
Например, если вы берете прерывание, но если одна из инструкций, уже находящихся в полете, также делает исключение, после того, как вы передали IF (выбор инструкций), но докакая-либо инструкция в прерывании зафиксирована, которая имеет приоритет?A: это зависитИ с такими вещами очень трудно иметь дело.
--- +++ Фольклор: пакетная обработка прерываний ОС для мэйнфреймов
Это скорее похоже на то, как сообщают некоторые операционные системы мэйнфреймов IBM.работали:
- со всеми прерываниями, заблокированными в нормальном режиме работы, кроме прерывания по таймеру;
- при прерывании по таймеру вы разблокируете прерывания и обрабатываете их все;
- и затем возврат к нормальной работе с режимом блокировки прерываний
Возможно, они могут использовать такой режим «пакетного прерывания» только при большой загрузке;при небольшой загрузке они могут не блокировать прерывания.
--- +++ Исключения отложенной проверки машины
Идея отсрочки прерываний для предоставления командам, уже находящимся в конвейере, шансов на выполнение, такжеаналогично тому, что я называю Исключением проверки отложенного компьютера - концепция, которую я включил в первоначальную архитектуру проверки компьютеров семейства Intel P6, примерно в 1991-1996 гг., но которая, похоже, не была выпущена.
Вот в чем проблема:ошибки машинной проверки, такие как (не) исправимые ошибки ECC, могут появиться ПОСЛЕ того, как инструкция удалилась (т. е. после того, как предположительно более молодые инструкции зафиксировали состояние, например, записанные регистры), или ДО того, как инструкция удалилась.
Классическим примером ошибок AFTER является неисправимый ECC, срабатывающий из хранилища, которое помещается в буфер записи по окончании.Практически все современные машины делают это, все машины с TSO, что в значительной степени означает, что всегда есть вероятность неточной ошибки проверки машины, которая могла бы быть точной, если вы позаботились о том, чтобы не буферизовать хранилища.
Классический пример ошибок ДО ... это каждая инструкция на любой машине с конвейером.Но что еще более интересно, ошибки в инструкциях неправильного пути, в тени неправильного предсказания ветви.
Когда инструкция загрузки получает неисправимую ошибку ECC, у вас есть два варианта:
(1) выможет немедленно привести к цепочке, убив не только инструкции МОЛОДЕЖНО, чем инструкцию загрузки, но и любые СТАРЫЕ инструкции
(2), или вы можете написать какой-нибудь код состояния в логику, управляющую спекуляцией, и принять исключение вотставка.Это в значительной степени то, что вы должны сделать для ошибки страницы, и это делает такие ошибки точными, помогая отладке.
(3) Но что, если инструкция загрузки, получившая неисправимую ошибку ECC, была неверной инструкцией пути и никогда не удалялась из-за того, что более ранняя ветвь рейса ошибочно предсказала и пошла другим путем?
Ну, вымог бы написать статус, чтобы попытаться сделать его точным.Вы должны иметь счетчики точных ошибок и неточных ошибок.В противном случае вы могли бы проигнорировать ошибку в такой инструкции неправильного пути - в конце концов, если это серьезная ошибка, к ней либо прикоснутся снова, либо это может не произойти. / Например, возможно, что ошибка будет архитектурно молчать -например, плохая строка кэша может быть перезаписана хорошей строкой кэша для того же адреса.
И, если вы действительно хотите, вы можете установить бит так, чтобы, если старая ветка ошибалась, вы брали проверку компьютераисключение в этот момент времени.
Такая ошибка не возникнет в программном счетчике, связанном с инструкцией, которая вызвала ошибку, но все равно может иметь иное точное состояние.
Я вызываю (2отложить исключение проверки машины;(3) это то, как вы могли бы справиться с отсрочкой.
IIRC, все исключения проверки компьютеров Intel P6 были неточными.
--- ++ С другой стороны: еще быстрее
Итак, мы обсудили
0) немедленное выполнение прерывания или, если прерывания заблокированы, выполнение инструкций и микроинструкций до достижения точки разблокирования прерывания.А затем сбросить все инструкции в полете.
1) пытаться выполнить инструкции в конвейере, чтобы избежать напрасной работы.
Но есть и третья возможность:
-1) если у вас есть контрольные точки состояния микроархитектуры, немедленно выполняйте прерывание, никогда не дожидаясь точки разблокирования прерывания.Что вы можете сделать только в том случае, если у вас есть контрольная точка всех соответствующих состояний в самой последней точке «безопасно принять прерывание».
Это даже быстрее, чем 0), поэтому я обозначил ее -1),Но для этого нужны контрольные точки, которые используют многие, но не все агрессивные процессоры - например, Intel P6 не использует контрольные точки.И такие контрольные точки после выхода на пенсию становятся интересными при наличии разделяемой памяти - в конце концов, вы можете выполнять операции с памятью, такие как загрузка и сохранение, в то время как прерывания блокируются.И вы даже можете общаться между процессорами.Даже аппаратная транзакционная память обычно этого не делает.
--- + Исключения отмечают затронутые инструкции
И наоборот, исключения, такие как ошибки страниц, отмечают затронутые инструкции.
Когда эта инструкция собирается зафиксировать, в этот момент все последующие инструкции после исключения сбрасываются и выборка инструкций перенаправляется.
Вероятно, выборка инструкций может быть отменена раньше, так как неправильные прогнозы ветвления уже обрабатываются на большинстве процессоров, в тот момент, когда мы знаем, что произойдет исключение.Я не знаю никого, кто это делает.В текущих рабочих нагрузках исключения не так важны.
--- + «Программные прерывания»
«Программные прерывания» - это инструкция с неправильным названием, обычно связанная с системными вызовами.
Можно предположить, что такая инструкция может быть обработана без прерывания конвейера, предсказанного как ветвь.
Однако все машины, с которыми я знаком, сериализуются в некотором роде.По-моему, они не переименовывают уровень привилегий.
--- + "Точные прерывания", EMON, PEBS
В другом плакате упоминаются точные прерывания.
Этоисторический термин.На большинстве современных машин прерывания определяются как точные.Старые машины с неточными прерываниями не были очень успешными на рынке.
Однако у меня было альтернативное значение: когда я заставил Intel добавить возможность создавать прерывания на счетчике производительностиПереполнение, сначала с использованием внешнего оборудования, а затем внутри процессора, в первые несколько поколений было совершенно неточным.
Например, вы можете установить счетчик для подсчета количества удаленных инструкций.Логика отмены (RL) будет видеть команды отмены и сигнализировать о схеме мониторинга событий производительности (EMON).Для отправки этого сигнала из RL в EMON может потребоваться два или три такта.EMON увеличит счетчик, а затем увидит переполнение.Переполнение вызовет запрос прерывания к APIC (расширенный программируемый контроллер прерываний).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 сбрасываются из конвейера.
Я надеюсь --- + Позднее добавление о ранних компьютерах