stringtranslate.com

Peligro (arquitectura informática)

En el dominio del diseño de la unidad central de procesamiento (CPU) , los peligros son problemas con la canalización de instrucciones en las microarquitecturas de la CPU cuando la siguiente instrucción no se puede ejecutar en el siguiente ciclo de reloj [1] y puede conducir potencialmente a resultados de cálculo incorrectos. Tres tipos comunes de peligros son los peligros de datos, los peligros estructurales y los peligros de control (peligros de ramificación). [2]

Se utilizan varios métodos para hacer frente a los peligros, incluidos los atascos /burbujas de tuberías, el reenvío de operandos y, en el caso de una ejecución fuera de orden , el método de puntuación y el algoritmo de Tomasulo .

Fondo

Las instrucciones en un procesador canalizado se ejecutan en varias etapas, de modo que en un momento dado se procesan varias instrucciones en las distintas etapas del canal, como buscar y ejecutar. Hay muchas microarquitecturas diferentes de canalización de instrucciones y es posible que las instrucciones se ejecuten fuera de orden . Se produce un peligro cuando dos o más de estas instrucciones simultáneas (posiblemente fuera de servicio) entran en conflicto.

Tipos

Peligros de datos

Los peligros de los datos ocurren cuando las instrucciones que muestran dependencia de los datos modifican los datos en diferentes etapas de una canalización. Ignorar los posibles peligros de los datos puede dar lugar a condiciones de carrera (también denominadas peligros de carrera). Hay tres situaciones en las que puede ocurrir un riesgo de datos:

  1. lectura después de escritura (RAW), una verdadera dependencia
  2. escribir después de leer (WAR), una antidependencia
  3. escritura tras escritura (WAW), una dependencia de salida

La lectura tras lectura (RAR) no es un caso peligroso.

Considere dos instrucciones i1 e i2 , donde i1 ocurre antes de i2 en el orden del programa.

Leer después de escribir (RAW)

( i2 intenta leer una fuente antes de que i1 escriba en ella) Un riesgo de lectura después de escritura (RAW) se refiere a una situación en la que una instrucción se refiere a un resultado que aún no se ha calculado o recuperado. Esto puede ocurrir porque aunque una instrucción se ejecuta después de una instrucción anterior, la instrucción anterior se ha procesado solo parcialmente a través de la canalización.

Ejemplo

Por ejemplo:

i1. R2 <- R5 + R8i2. R4 <- R2 + R8

La primera instrucción calcula un valor que se guardará en el registro R2 y la segunda utilizará este valor para calcular un resultado para el registro R4 . Sin embargo, en una canalización , cuando se recuperan los operandos para la segunda operación, los resultados de la primera aún no se han guardado y, por lo tanto, se produce una dependencia de datos.

Se produce una dependencia de datos con la instrucción i2 , ya que depende de la finalización de la instrucción i1 .

Escribir después de leer (GUERRA)

( i2 intenta escribir un destino antes de que i1 lo lea ) Un peligro de escritura después de lectura (WAR) representa un problema con la ejecución concurrente.

Ejemplo

Por ejemplo:

i1. R4 <- R1 + R5
i2. R5 <- R1 + R2

En cualquier situación en la que exista la posibilidad de que i2 finalice antes que i1 (es decir, con ejecución simultánea), se debe garantizar que el resultado del registro R5 no se almacene antes de que i1 haya tenido la oportunidad de recuperar los operandos.

Escritura tras escritura (WAW)

( i2 intenta escribir un operando antes de que i1 lo escriba ) Puede ocurrir un peligro de escritura después de escritura (WAW) en un entorno de ejecución concurrente .

Ejemplo

Por ejemplo:

i1. R5 <- R4 + R7i2. R5 <- R1 + R3

La reescritura (WB) de i2 debe retrasarse hasta que i1 termine de ejecutarse.

Peligros estructurales

Un peligro estructural ocurre cuando dos (o más) instrucciones que ya están en proceso necesitan el mismo recurso. El resultado es que la instrucción debe ejecutarse en serie en lugar de en paralelo durante una parte del proceso. Los peligros estructurales a veces se denominan peligros de recursos.

Ejemplo: una situación en la que varias instrucciones están listas para ingresar a la fase de ejecución de instrucciones y hay una única ALU (Unidad Aritmética Lógica). Una solución a tal peligro de recursos es aumentar los recursos disponibles, como tener múltiples puertos en la memoria principal y múltiples unidades ALU (Unidad Aritmética Lógica).

Controlar los peligros (peligros de rama o peligros de instrucción)

El peligro de control ocurre cuando la tubería toma decisiones equivocadas en la predicción de bifurcaciones y, por lo tanto, introduce instrucciones en la tubería que posteriormente deben descartarse. El término riesgo de rama también se refiere a un riesgo de control.

Eliminando peligros

Genérico

Tubería burbujeando

Hacer burbujas en la tubería , también denominado rotura de tubería o parada de tubería , es un método para evitar riesgos de datos, estructurales y de rama. A medida que se obtienen las instrucciones, la lógica de control determina si podría ocurrir o ocurrirá un peligro. Si esto es cierto, entonces la lógica de control no inserta ninguna operación ( NOP ) en la tubería. Por lo tanto, antes de que se ejecute la siguiente instrucción (que causaría el peligro), la anterior habrá tenido tiempo suficiente para terminar y prevenir el peligro. Si el número de NOP es igual al número de etapas en la tubería, el procesador ha sido eliminado de todas las instrucciones y puede proceder sin peligros. Todas las formas de estancamiento introducen un retraso antes de que el procesador pueda reanudar la ejecución.

El vaciado de la tubería ocurre cuando una instrucción de bifurcación salta a una nueva ubicación de memoria, invalidando todas las etapas anteriores de la tubería. Estas etapas previas se borran, permitiendo que el oleoducto continúe con la nueva instrucción indicada por la sucursal. [3] [4]

Peligros de datos

Existen varias soluciones y algoritmos principales que se utilizan para resolver los peligros de los datos:

En el caso de ejecución fuera de orden , el algoritmo utilizado puede ser:

La tarea de eliminar dependencias de datos se puede delegar al compilador, que puede completar una cantidad adecuada de instrucciones NOP entre instrucciones dependientes para garantizar el funcionamiento correcto, o reordenar las instrucciones cuando sea posible.

reenvío de operandos

Ejemplos

En los siguientes ejemplos, los valores calculados están en negrita , mientras que los números de registro no.

Por ejemplo, escribir el valor 3 en el registro 1 (que ya contiene un 6), y luego sumar 7 al registro 1 y almacenar el resultado en el registro 2, es decir:

i0: R1 = 6
i1: R1 = 3
i2: R2 = R1 + 7 = 10

Después de la ejecución, el registro 2 debe contener el valor 10 . Sin embargo, si i1 (escriba 3 en el registro 1) no sale completamente de la canalización antes de que i2 comience a ejecutarse, significa que R1 no contiene el valor 3 cuando i2 realiza su suma. En tal caso, i2 suma 7 al antiguo valor del registro 1 ( 6 ), por lo que el registro 2 contiene 13 , es decir:

i0: R1 = 6
i2: R2 = R1 + 7 = 13
i1: R1 = 3

Este error se produce porque i2 lee el Registro 1 antes de que i1 haya confirmado/almacenado el resultado de su operación de escritura en el Registro 1. Entonces, cuando i2 lee el contenido del Registro 1, el registro 1 todavía contiene 6 , no 3 .

El reenvío (que se describe a continuación) ayuda a corregir dichos errores dependiendo del hecho de que la salida de i1 (que es 3 ) puede ser utilizada por instrucciones posteriores antes de que el valor 3 se confirme o almacene en el Registro 1.

El reenvío aplicado al ejemplo significa que no hay que esperar para confirmar/almacenar la salida de i1 en el Registro 1 (en este ejemplo, la salida es 3 ) antes de que esa salida esté disponible para la siguiente instrucción (en este caso, i2). El efecto es que i2 usa el valor correcto (el más reciente) del Registro 1: la confirmación/almacenamiento se realizó inmediatamente y no se canalizó.

Con el reenvío habilitado, la etapa de decodificación/ejecución de instrucciones (ID/EX) de la canalización ahora tiene dos entradas: el valor leído del registro especificado (en este ejemplo, el valor 6 del Registro 1) y el nuevo valor del Registro 1. (en este ejemplo, este valor es 3 ) que se envía desde la siguiente etapa Ejecución de instrucciones/Acceso a memoria (EX/MEM). Se utiliza lógica de control adicional para determinar qué entrada utilizar.

Peligros de control (peligros de rama)

Para evitar riesgos de control, las microarquitecturas pueden:

En el caso de que una rama provoque una burbuja en la tubería después de que instrucciones incorrectas hayan ingresado a la tubería, se debe tener cuidado para evitar que cualquiera de las instrucciones cargadas incorrectamente tenga algún efecto en el estado del procesador, excluyendo la energía desperdiciada al procesarlas antes de que se descubra que son cargado incorrectamente.

Otras técnicas

La latencia de la memoria es otro factor al que los diseñadores deben prestar atención, porque el retraso podría reducir el rendimiento. Los diferentes tipos de memoria tienen diferentes tiempos de acceso a la memoria. Por lo tanto, al elegir un tipo de memoria adecuado, los diseñadores pueden mejorar el rendimiento de la ruta de datos canalizados. [5]

Ver también

Referencias

  1. ^ Patterson y Hennessy 2009, pág. 335.
  2. ^ Patterson y Hennessy 2009, págs. 335–343.
  3. ^ "Esquemas de predicción de sucursales". cs.iastate.edu . 2001-04-06 . Consultado el 19 de julio de 2014 .
  4. ^ "Peligros de control y datos". clases.soe.ucsc.edu . 2004-02-23 . Consultado el 19 de julio de 2014 .
  5. ^ Cheng, Ching-Hwa (27 de diciembre de 2012). "Ejemplo de diseño de latencia de memoria útil para desarrollar un microprocesador integrado de alto rendimiento de tubería preventiva de peligros". Diseño VLSI . 2013 : 1–10. doi : 10.1155/2013/425105 .

General

enlaces externos