En el dominio del diseño de la unidad central de procesamiento (CPU) , los peligros son problemas con el flujo 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 potencialmente conducir a resultados de cálculo incorrectos. Tres tipos comunes de peligros son los peligros relacionados con los datos, los peligros estructurales y los peligros de control (peligros de ramificación). [2]
Hay varios métodos que se utilizan para hacer frente a los peligros, incluidos los bloqueos de la tubería / burbujeo de la tubería, 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 de canalización se ejecutan en varias etapas, de modo que en un momento dado se procesan varias instrucciones en las distintas etapas de la canalización, como buscar y ejecutar. Hay muchas microarquitecturas de canalización de instrucciones diferentes , y las instrucciones pueden ejecutarse 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
Riesgos 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 tubería. Ignorar los peligros potenciales de los datos puede resultar en condiciones de carrera (también denominadas peligros de carrera). Hay tres situaciones en las que puede ocurrir un riesgo de datos:
- lectura tras escritura (RAW), una verdadera dependencia
- escribir después de leer (WAR), una anti-dependencia
- escritura tras escritura (WAW), una dependencia de salida
Leer tras leer (RAR) no es un caso de peligro.
Considere dos instrucciones i1 y i2 , con i1 ocurriendo antes i2 en el orden del programa.
Leer después de escribir (RAW)
( i2 intenta leer una fuente antes i1 escribe en él) Un peligro de datos 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 + R3i2. R4 <- R2 + R3
La primera instrucción es calcular un valor que se guardará en el registro. R2 , y el segundo usará este valor para calcular un resultado para el registro R4 . Sin embargo, en una canalización , cuando se obtienen 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 (WAR)
( i2 intenta escribir un destino antes de que lo lea i1 ) Un peligro de datos de escritura tras 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 con la posibilidad de que i2 puede terminar antes i1 (es decir, con ejecución concurrente), debe asegurarse que el resultado del registro R5 no se almacena antes i1 ha tenido la oportunidad de obtener los operandos.
Escritura tras escritura (WAW)
( i2 intenta escribir un operando antes de que lo escriba i1 ) Puede producirse un peligro de datos de escritura tras escritura (WAW) en un entorno de ejecución simultánea .
Ejemplo
Por ejemplo:
i1. R2 <- R4 + R7i2. R2 <- R1 + R3
La reescritura (WB) de i2 debe retrasarse hasta i1 termina de ejecutarse.
Riesgos 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 para una parte de la canalización. En ocasiones, los peligros estructurales se denominan peligros relacionados con los recursos.
Ejemplo: una situación en la que varias instrucciones están listas para entrar en la fase de ejecución de instrucciones y hay una sola ALU (Unidad Aritmética Lógica). Una solución para 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).
Peligros de control (peligros de rama o peligros de instrucción)
El peligro de control ocurre cuando la tubería toma decisiones incorrectas en la predicción de rama y, por lo tanto, trae instrucciones a la tubería que posteriormente deben descartarse. El término peligro de rama también se refiere a un peligro de control.
Eliminando peligros
Genérico
Tubería burbujeante
Hacer burbujear la tubería , también denominado rotura de tubería o bloqueo de la tubería , es un método para excluir los peligros de datos, estructurales y de ramales. A medida que se obtienen las instrucciones, la lógica de control determina si un peligro podría ocurrir o si ocurrirá. Si esto es cierto, entonces la lógica de control inserta ninguna operación s NOP s) 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 finalizar y prevenir el peligro. Si el número de NOP s es igual al número de etapas en la tubería, el procesador ha sido liberado de todas las instrucciones y puede continuar sin peligros. Todas las formas de estancamiento introducen un retraso antes de que el procesador pueda reanudar la ejecución.
El vaciado de la canalización se produce cuando una instrucción de bifurcación salta a una nueva ubicación de memoria, invalidando todas las etapas anteriores de la canalización. Estas etapas anteriores se borran, lo que permite que la tubería continúe con la nueva instrucción indicada por la rama. [3] [4]
Riesgos de datos
Hay varias soluciones y algoritmos principales que se utilizan para resolver los peligros de los datos:
- insertar una burbuja de canalización siempre que se encuentre una dependencia de lectura después de escritura (RAW), garantizada para aumentar la latencia, o
- utilizar la ejecución fuera de orden para prevenir potencialmente la necesidad de burbujas en la tubería
- usar el reenvío de operandos para usar datos de etapas posteriores en la tubería
En el caso de ejecución fuera de orden , el algoritmo utilizado puede ser:
- marcador , en cuyo caso se necesita una burbuja de canalización solo cuando no hay una unidad funcional disponible
- el algoritmo de Tomasulo , que utiliza el cambio de nombre de registros , lo que permite la emisión continua de instrucciones
La tarea de eliminar las dependencias de datos se puede delegar al compilador, que puede completar un número apropiado de Instrucciones NOP entre instrucciones dependientes para garantizar un funcionamiento correcto o reordenar instrucciones cuando sea posible.
Reenvío de operandos
Ejemplos de
- 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 agregar 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 adición. En tal caso, i2 agrega 7 al antiguo valor del registro 1 ( 6 ), por lo que el registro 2 contiene 13 en su lugar, es decir:
i0: R1 = 6 i2: R2 = R1 + 7 = 13 i1: R1 = 3
Este error ocurre 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. Por lo tanto, cuando i2 está leyendo el contenido del Registro 1, el registro 1 todavía contiene 6 , no 3 .
El reenvío (descrito a continuación) ayuda a corregir dichos errores al depender 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 / 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 poner esa salida a disposición de la instrucción subsiguiente (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 instrucción / Acceso a memoria (EX / MEM). La lógica de control adicional se usa para determinar qué entrada usar.
Control de peligros (peligros de rama)
Para evitar riesgos de control, las microarquitecturas pueden:
- insertar una burbuja de canalización (discutida anteriormente), garantizada para aumentar la latencia , o
- usar la predicción de rama y esencialmente hacer conjeturas sobre qué instrucciones insertar, en cuyo caso solo se necesitará una burbuja de canalización en el caso de una predicción incorrecta
En el caso de que una rama provoque una burbuja en la tubería después de que hayan ingresado instrucciones incorrectas en 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 el desperdicio de energía procesándolas antes de que se descubra que están en mal estado. cargado incorrectamente.
Otras tecnicas
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 canalizada. [5]
Ver también
Referencias
- ^ Patterson y Hennessy 2009 , p. 335.
- ^ Patterson y Hennessy 2009 , págs. 335-343.
- ^ "Esquemas de predicción de rama" . cs.iastate.edu . 2001-04-06 . Consultado el 19 de julio de 2014 .
- ^ "Riesgos de control y datos" . classes.soe.ucsc.edu . 2004-02-23 . Consultado el 19 de julio de 2014 .
- ^ 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
- Patterson, David ; Hennessy, John (2009). Organización y diseño informático (4ª ed.). Morgan Kaufmann . ISBN 978-0-12-374493-7.
- Patterson, David; Hennessy, John (2011). Arquitectura informática: un enfoque cuantitativo (5ª ed.). Morgan Kaufmann . ISBN 978-0-12-383872-8.
- Shen, John P .; Lipasti, Mikko H. (2013) [2004]. "2.2.3.2 Identificación de los peligros de las tuberías" . Diseño de procesador moderno: fundamentos de los procesadores superescalares . págs. 73–78. ISBN 9781478610762.
enlaces externos
- "Canalización automática de especificaciones de ruta de datos transaccionales" (PDF) . Consultado el 23 de julio de 2014 .
- Tulsen, Dean (18 de enero de 2005). "Riesgos de oleoductos" (PDF) .