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

Question

Предположим, что существует 5-ступенчатая конвейерная архитектура (IF = извлечение инструкций, ID = декодирование инструкций, EX = выполнение, MEM = доступ к памяти, WB = обратная запись в регистр). Необходимо выполнить 4 инструкции.

(Эти примеры инструкций не точны, но я считаю, что смысл будет понятен)

В пятом такте эти инструкции будут в конвейере, как показано ниже.

Добавить a, b, c [IF ID EX MEM WB]

Добавьте a, b, d [IF ID EX MEM]

Добавьте a, b, e [IF ID EX]

Добавьте a, b, f [IF ID]

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

Answer 1

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

Обычно, по крайней мере в 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 (точная выборка на основе событий). http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf.

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

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

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

Answer 2

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

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

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

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

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

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