computer-architecture - book - computer architecture pdf

Cuando ocurre una interrupción, ¿qué sucede con las instrucciones en la tubería?

Question

Supongamos una arquitectura de canalización de 5 etapas (IF = Obtención de instrucción, ID = Decodificación de instrucción, EX = Ejecutar, MEM = Acceso a memoria, WB = Registrar respuesta). Hay 4 instrucciones que deben ejecutarse.

(Estas instrucciones de muestra no son precisas, pero creo que se entendería el punto)

En el quinto ciclo de reloj, estas instrucciones estarán en tramitación como se muestra a continuación.

Añadir a, b, c [IF ID EX MEM WB]

Añadir a, b, d [IF ID EX MEM]

Añadir a, b, e [IF ID EX]

Añadir a, b, f [IF ID]

Ahora bien, si se produce una interrupción de hardware lo que sucede con estas instrucciones. ¿Se manejará la interrupción solo después de que se hayan ejecutado todas las instrucciones en la tubería? ¿Las interrupciones y excepciones del software se manejarán de una manera diferente?

Answer 1

Para interrupciones precisas, las instrucciones en vuelo antes de que la etapa IF salte al ISR se retiran normalmente. Cuando el ISR regresa, la ejecución se reanuda comenzando con la siguiente instrucción después de la última instrucción retirada del proceso original. En otras palabras, las interrupciones precisas siempre ocurren entre las instrucciones.

El procesamiento de interrupciones síncronas es un poco diferente. Tomando x86 como ejemplo, las excepciones síncronas vienen en tres tipos, trampas, fallas y abortos.

Una trampa, como INT3, hace que el núcleo empuje la instrucción después de la trampa en la pila, de modo que cuando el ISR regresa, el núcleo no vuelve a ejecutar la misma instrucción de captura sin sentido.

Un error, como un error de página, hace que el núcleo empuje la instrucción de error en la pila, de modo que cuando el ISR regrese, el núcleo volverá a ejecutar la instrucción de error, probablemente ahora en circunstancias que eviten el mismo error nuevamente.

Una anulación, como una doble falla, es un problema irrecuperable y fatal en el que el procesador no puede reanudar la ejecución donde se detuvo.

El contenido del marco de la pila de interrupciones empujado por el núcleo antes de ingresar al ISR varía en función del caso al que se refiere.

Answer 2

Primero, la terminología:

Normalmente, al menos en Intel, una interrupción es algo que viene del mundo exterior. Por lo general, no está sincronizado con las instrucciones que se ejecutan en el procesador, es decir, es una interrupción externa asíncrona.

En la terminología de Intel, una excepción es algo causado por instrucciones que se ejecutan en el procesador. Por ejemplo, un fallo de página, o una trampa de instrucciones indefinida.

--- + Interrumpe enjuagar todas las instrucciones en vuelo

En todas las máquinas con las que estoy familiarizado (p. Ej., Todos los procesadores Intel desde P5 (trabajé en P6), AMD x86, ARM, MIPS) cuando se recibe la señal de interrupción, las instrucciones en la tubería casi siempre se desechan.

La única razón por la que digo "casi siempre" es que en algunas de estas máquinas no siempre está en un lugar donde se le permite recibir una interrupción. Entonces, proceda al siguiente lugar donde se permite una interrupción (cualquier límite de instrucción, normalmente) y DESPUÉS, deseche todas las instrucciones en tramitación.

Para el caso, las interrupciones pueden estar bloqueadas. Así que continúas hasta que se desbloquean las interrupciones, y ENTONCES las tiras.

Ahora, estas máquinas no son exactamente simples tuberías de 5 etapas. Sin embargo, esta observación, de que la mayoría de las máquinas desechan todas las instrucciones en la tubería, en etapas antes de la etapa donde vive la lógica de interrupción, sigue siendo casi universalmente cierta.

En las máquinas simples, la lógica de interrupción suele residir en la última etapa de la tubería, WB, que corresponde aproximadamente al paso de compilación de las máquinas avanzadas. Algunas veces se mueve a un pipestage justo antes, por ejemplo, MEM en su ejemplo. Por lo tanto, en tales máquinas, todas las instrucciones en IF ID EX, y generalmente MEM, se desechan.

--- ++ Por qué me importa: Evitar el trabajo perdido

Este tema es cercano y querido para mi corazón porque he propuesto NO hacer esto. Por ejemplo, en las visitas de los clientes mientras planeamos construir el P6, les pregunté a los clientes cuál preferían: interrupciones de menor latencia, instrucciones de descarga que están en vuelo o un rendimiento ligeramente mayor, permitiendo que al menos algunas de las instrucciones en vuelo se completen. a costa de una latencia ligeramente más larga.

Sin embargo, aunque algunos clientes prefirieron este último, optamos por hacer lo tradicional, enjuagando de inmediato. Aparte de la menor latencia, la razón principal es la complejidad:

Por ejemplo, si toma una interrupción, pero si una de las instrucciones que ya están en vuelo también recibe una excepción, después de haber realizado el IF (recuperación de instrucciones) pero antes de que se haya confirmado alguna instrucción de la interrupción, ¿cuál tiene prioridad? A: depende. Y ese tipo de cosas es un dolor con el que lidiar.

--- +++ Folklore: Mainframe OS Interrupt Batching

Esto es más bien como la forma en que se informa que han operado algunos sistemas operativos de mainframe de IBM:

• con todas las interrupciones bloqueadas en funcionamiento normal, excepto la interrupción del temporizador;
• en la interrupción del temporizador, desbloquea las interrupciones y las manejas todas;
• y luego volver al funcionamiento normal con interrupciones en modo bloqueado

Posiblemente, solo podrían usar ese modo de "interrupción de procesamiento por lotes" cuando están muy cargados; Si están ligeramente cargados, es posible que no bloqueen las interrupciones.

--- +++ Excepciones de verificación de máquina diferida

La idea de diferir las interrupciones para dar a las instrucciones que ya están en trámite la oportunidad de ejecutar también es similar a lo que llamo la Excepción de verificación diferida de la máquina: un concepto que incluí en la arquitectura de verificación de máquinas original de la familia Intel P6, alrededor de 1991-1996, pero que parece no haber sido puesto en libertad.

Aquí está el problema: errores de comprobación de la máquina como (des) errores ECC corregibles pueden ocurrir DESPUÉS de que una instrucción se haya retirado (es decir, después de que supuestamente las instrucciones más jóvenes hayan estado en estado, por ejemplo, registros escritos), o ANTES de que la instrucción se haya retirado.

El ejemplo clásico de errores AFTER es un ECC incorregible activado por una tienda que se coloca en un búfer de escritura en la graduación. Casi todas las máquinas modernas hacen esto, todas las máquinas con TSO, lo que significa que siempre existe la posibilidad de un error impreciso en la verificación de la máquina que podría haber sido preciso si le importara lo suficiente como para no almacenar en búfer.

El ejemplo clásico de ANTES de los errores es ... bueno, cada instrucción, en cualquier máquina con una tubería. Pero, lo que es más interesante, los errores en las instrucciones de ruta incorrecta, a la sombra de una predicción errónea de una rama.

Cuando una instrucción de carga recibe un error ECC incorregible, tiene dos opciones:

(1) usted podría tirar de la cadena de inmediato, matando no solo las instrucciones MÁS JOVEN que la instrucción de carga, sino también cualquier instrucción ANTIGUA

(2) o podría escribir algún tipo de código de estado en la lógica que controla la especulación, y aceptar la excepción en el retiro. Esto es más o menos lo que tiene que hacer por un error de página, y hace que esos errores sean precisos, lo que ayuda a la depuración.

(3) Pero, ¿qué sucede si la instrucción de carga que obtuvo el error ECC incorregible fue una instrucción de ruta incorrecta y nunca se retira debido a que una rama de vuelo más antigua se pronosticó mal y se fue de otra manera?

Bueno, podrías escribir el estado para intentar que sea preciso. Debe tener contadores de errores precisos y errores imprecisos. De lo contrario, podría ignorar un error en una instrucción de ruta errónea. Después de todo, si es un error grave, se volverá a tocar o podría no serlo. Por ejemplo, es posible que el error sea arquitectónicamente silencioso. por ejemplo, una línea de caché mala puede ser sobrescrita por una buena línea de caché para la misma dirección.

Y, si realmente lo desea, puede establecer un poco para que, si una rama anterior predice incorrectamente, tome la excepción de verificación de la máquina en ese momento.

Dicho error no se produciría en un contador de programa asociado con la instrucción que causó el error, pero aún así podría tener un estado preciso.

Llamo (2) aplazando una excepción de verificación de máquina; (3) es cómo podría manejar el aplazamiento.

IIRC, todas las excepciones de verificación de la máquina Intel P6 fueron imprecisas.

--- ++ En la mano de agarre: aún más rápido

Entonces, hemos discutido

0) tomar la interrupción inmediatamente, o, si las interrupciones están bloqueadas, ejecutar instrucciones y microinstrucciones hasta que se alcance un punto de interrupción desbloqueada. Y luego enjuagar todas las instrucciones en vuelo.

1) tratando de ejecutar las instrucciones en la tubería, para evitar el desperdicio de trabajo.

Pero hay una tercera posibilidad:

-1) si tiene puntos de control de estado de microarquitectura, tome la interrupción de inmediato, sin esperar a que se interrumpa un punto desbloqueado. Lo que solo puede hacer si tiene un punto de control de todos los estados relevantes en el punto más reciente de "seguro para tomar una interrupción".

Esto es incluso más rápido que 0), por lo que lo etiqueté -1). Pero requiere puntos de control, que utilizan muchas pero no todas las CPU agresivas, por ejemplo, Intel P6 no usa puntos de control. Y dichos puntos de control posteriores a la jubilación se vuelven extraños en presencia de memoria compartida; después de todo, puede realizar operaciones de memoria como cargas y almacenes mientras se bloquean las interrupciones. E incluso puedes comunicarte entre CPUs. Incluso la memoria transaccional de hardware no suele hacer eso.

--- + Excepciones marcan las instrucciones afectadas.

A la inversa, excepciones, cosas como fallas de página, marcan la instrucción afectada.

Cuando esa instrucción está a punto de comprometerse, en ese momento se borran todas las instrucciones posteriores a la excepción y se redirige la búsqueda de instrucciones.

Posiblemente, la recuperación de la instrucción podría ser repetida antes, la forma en que las predicciones erróneas de las ramas ya se manejan en la mayoría de los procesadores, en el momento en que sabemos que ocurrirá la excepción. No conozco a nadie que haga esto. En las cargas de trabajo actuales, las excepciones no son tan importantes.

--- + "Interrupciones de software"

Las "interrupciones de software" son instrucciones erróneas que generalmente se asocian con llamadas al sistema.

Posiblemente, tal instrucción podría ser manejada sin interrumpir la tubería, predicha como una rama.

Sin embargo, todas las máquinas con las que estoy familiarizado se serializan de alguna manera. En mi lenguaje, no cambian el nombre del nivel de privilegio.

--- + "Interrupciones precisas", EMON, PEBS

Otro cartel mencionado precisa interrupciones.

Este es un término histórico. En la mayoría de las máquinas modernas las interrupciones se definen para ser precisas. Las máquinas más antiguas con interrupciones imprecisas no han tenido mucho éxito en el mercado.

Sin embargo, hay un significado alternativo en el que participé en la introducción: cuando conseguí que Intel agregara la capacidad de producir una interrupción en el desbordamiento del contador de rendimiento, primero utilizando hardware externo y luego dentro de la CPU, en las primeras generaciones , completamente impreciso.

Por ejemplo, puede configurar el contador para que cuente el número de instrucciones retiradas. La lógica de retiro (RL) vería las instrucciones retirarse y señalaría el circuito de monitoreo de eventos de rendimiento (EMON). Es posible que se necesiten dos o tres ciclos de reloj para enviar esta señal de RL a EMON. EMON incrementaría el contador y luego vería que había un desbordamiento. El desbordamiento provocaría una solicitud de interrupción al APIC (Controlador de interrupción programable avanzado). La APIC podría tomar algunos ciclos para averiguar qué estaba sucediendo y luego señalar la lógica de retiro.

Es decir, la interrupción de EMON sería señalada de manera imprecisa. No en el momento del evento, pero algún tiempo después.

¿Por qué esta imprecisión? Bueno, en 1992-6, el hardware de medición del rendimiento no era una alta prioridad. Estábamos aprovechando el hardware de interrupción existente. Los mendigos no pueden elegir.

Pero además, algunas actuaciones son intrínsecamente imprecisas. Por ejemplo, ¿cuándo señala una interrupción por una falta de caché en una instrucción especulativa que nunca se retira? (Tengo un esquema al que llamé eventos EMON diferidos, pero esto todavía se considera demasiado costoso). En realidad, ¿qué pasa con el caché en las instrucciones de la tienda, donde la tienda se coloca en un búfer de la tienda y la instrucción ya se ha retirado?

Es decir, a veces los eventos de rendimiento ocurren después de que la instrucción con la que están asociados se ha comprometido (se ha retirado). A veces antes. Y a menudo no exactamente en la instrucción con la que están asociados.

Pero en todas las implementaciones hasta el momento, por lo que sé, estos eventos de rendimiento se tratan como interrupciones: las instrucciones existentes en la canalización se desechan.

Ahora, puede hacer que un evento de rendimiento sea preciso tratándolo como una trampa. Por ejemplo, si se trata de un evento como las instrucciones retiradas, puede tener la trampa de la lógica de retiro de inmediato, en lugar de tomar el circuito que describí anteriormente. Si ocurre antes en la tubería, puede tener el hecho de que ocurrió marcado en el estado de falla de la instrucción en el ROB (Reordenar Buffer). Algo como esto es lo que Intel ha hecho con PEBS (muestreo basado en eventos precisos). http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf .

Sin embargo, tenga en cuenta que no todos los eventos se pueden muestrear utilizando PEBS. Por ejemplo, PEBS en el ejemplo anterior puede contar las cargas que tuvieron un impacto de caché o no, pero no las tiendas (ya que las tiendas se producen más adelante).

Así que esto es como excepciones: el evento se entrega solo cuando la instrucción se retira. Debido a que, en cierto sentido, el evento no se ha producido por completo: es una instrucción de carga, que toma una falta de caché y luego se retira. Y las instrucciones después de la instrucción PEBS marcada se eliminan de la tubería.

Espero --- + Adición tardía sobre las primeras computadoras