UNIVERSIDAD NACIONAL DE SAN ANTONIO ABAD DEL CUSCO

Facultad de Cs. Químicas, Físicas y Matemáticas

C.P. Ingeniería Informática y de Sistemas

Organización y Arquitectura del Computador

Integrantes:

- Castro Del Carpio, Cristian

- Cuchillo Huaman, Javier

- Hermoza Salcedo, Fahed

- Huarhua Callañaupa, Lino Dario

- Paredes Rios, Conrad Humberto

Cusco, octubre 2013.

6.5DATA HAZARDS AND STALLS

6.6BRANCH HAZARDS

INTRODUCCION

Como se vio en exposiciones anteriores existen también “problemas de fuente de información” (pipeline hazards) los cuales se relacionan o involucran derivaciones, este punto dará a conocer mas de estas particularidades y tratara de explicar como mejorar estos casos.

ASUMIR QUE LA DERIVACIÓN NO SE TOMA

Explicación Como ya se explicó antes, esperar hasta que la

derivación este totalmente completa demanda demasiado tiempo debido a la lentitud de este mismo. Una solución común a este problema es asumir que la derivación NO VA SER TOMADA y así continuar la ejecución por el flujo de instrucciones secuenciales.

ACLARACIONES

Si la derivación es tomada , las instrucciones que han sido extraídas y decodificadas deben ser descartadas. La ejecución sigue con el objetivo de salto.

Si las derivaciones no son tomadas en la mitad del tiempo y cuesta poco descartar la instrucción, esta optimización reduce a la mitad el costo de el “riesgo de control” (control hazard).

DESCARTAR INSTRUCCIONES EXPLICACIÓN

Al descartar instrucciones , nosotros simplemente cambiamos el valor de controles originales a 0 segundos, tanto como lo hicimos para detener a un riesgo de uso de carga de datos.

La diferencia radica en que nosotros debemos cambiar también las 3 instrucciones en las etapas de : IF, ID y EX cuando la derivación alcanza la etapa MEM.

Descartar la función significa entonces que debemos ser capaces de eliminar instrucciones dentro de las etapas de IF,ID y EX de la fuente de información (pipeline).

REDUCIR EL DELAY O RETRASO DE LAS RAMAS

Explicación Una manera de mejorar el rendimiento de las

derivaciones es reducir el costo la derivación extraída. Hasta el momento asumimos que la siguiente rama

seleccionada por la PC es seleccionada por la etapa MEM, pero si nosotros movemos la ejecución de la derivación a un momento mas temprano en la fuente de información(pipeline), entonces algunas instrucciones necesitarían ser renovadas pero el costo seria menor.

Para este caso daremos uso de la Arquitectura MIPS que fue diseñada para dar apoyo rápido a cada ciclo particular de la derivaciones que podría ser transformado a canales con una pequeña penalidad.

Los diseñadores observaron que muchas ramas confían solo en un único test (igualdad de señales, por ejm) y que cada test no requiere una completa operación ALU pero no puede ser hecha a la sumo con algunas puertas. Cuando una decisión mas compleja en una derivación es requerida una separación de instrucciones que usa un ALU para realizar una comparación es requerida – una situación similar al uso de códigos condicionales para cada rama.

ACLARACIONES SOBRE EL FUNCIONAMIENTO EN LA PC

REQUERIMIENTOS PARA REALIZAR ESTE PROCESOMover la derivación a una etapa mas temprana requiere que 2

acciones ocurran antes:1) La parte fácil de este cambio es mover arriba la dirección de calculo. Esto debido

a que nosotros ya tenemos los valores de la PC y el campo inmediato en el registro de tubería IF/ID entonces nosotros solo movemos la derivación agregada del campo EX al campo ID , por supuesto el blanco de la derivación por el calculo de dirección va ser realizado por todas las instrucciones, pero solo usado cuando sea necesario.

2) La parte mas difícil es la decisión de la rama por si misma. Para cada rama igual, nosotros compararíamos los 2 registros leídos durante el campo ID para ver si ellos son iguales. Igualmente puede ser probada por los primeros respetivos bits de “ORing” y todos los resultados de “ORing”. Mover el test de un campo ID implica un reenvió adicional y detección de errores de hardware, ya que la derivación depende del resultado, la fuente de información(pipeline) debe trabajar apropiadamente con esta optimización.

PREDICCIÓN DINÁMICA DE DERIVACIONESAsumir que una derivación no es tomada es una forma simple de

predicción de ramas, en ese caso nosotros predecimos que ramas no serán tomadas y renovamos o actualizamos la fuente de información (pipeline) cuando esta esta equivocada, por la simple distribución de fuente de información (pipeline) en cinco etapas, tal enfoque, posiblemente junto con la predicción basada en compilador, es probablemente adecuada.

Con mas fuentes de información(pipelines) la penalidad de la derivación incrementa cuando se mide los ciclos de reloj. Similarmente, con múltiples problemas, la penalidad de la derivación incrementa en términos de instrucciones perdidas. Esta combinación significa que en una fuente de información (pipeline) agresiva, un simple esquema de predicción estática probablemente demande demasiado rendimiento. Como se menciono: con mas hardware es posible intentar predecir comportamiento de ramas durante la ejecución del programa

“Una aproximación es mirar la dirección de instrucciones y ver si la derivación que fue tomada la ultima vez fue ejecutada y si es así empezar a captar nuevas instrucción del mismo lugar como la ultima vez. Esta técnica es llamada PREDICCION DINAMICA DE DERIVACIONES”

IMPLEMENTACIÓN Una implementación de este enfoque es la Predicción de ramas en

buffer o implementación por tabla de historial.

Una predicción de ramas en buffer es una pequeña memoria indexada por la mas baja porción de dirección de la rama de instrucciones. La memoria contiene un bit que dice cuando la rama fue recientemente tomada o no.

6.7UTILIZANDO UN LENGUAJE DE DESCRIPCIÓN DE HARDWARE PARA DESCRIBIR Y MODELAR UNA TUBERÍA

UTILIZANDO UN LENGUAJE DE DESCRIPCIÓN DE HARDWARE PARA DESCRIBIR Y MODELAR UNA TUBERÍA

El modelo inicial ignora los peligros y adiciones a un modelo mas destacado de los cambios para el desvío, los peligros de datos y los peligros derivados.

6.8EXCEPCIONES

EXCEPCIONES E INTERRUPCIONES

� Los eventos “inesperados” requieren de un cambio en el control del flujo

� Excepción� Surge dentro del CPU

� Interrupciones� Desde un controlador externo de E/S

� Tratar con ellos sin sacrificar el desempeño es difícil

MOTIVOS POSIBLES DE LAS EXCEPCIONES

� Petición de un Dispositivo de E/S

� Requerimiento de un servicio del sistema por parte de un programa de usuario

� Uso de una instrucción no definida

� Mal funcionamiento de la circuitería

MANEJO DE EXCEPCIONES

� En el MIPS, las excepciones son administradas por un Coprocesador de Control del Sistema

� Guarda el PC de instrucciones ofensivas (o interrupciones)

� Guardar la indicación del problema� Saltar al administrador en 8000 00180

ACCIONES DEL ADMINISTRADOR

� Leer la causa, y transferir el administrador relevante

� Determinar la acción requerida� Si se restablece

� Tomar la acción correctiva

� Usar EPC(registro que contiene la dirección de la instrucción afectada) para regresar al programa

� De otra manera� Terminar el programa

� Reportar el error usando EPC

SEGMENTADO CON EXCEPCIONES

PROPIEDADES DE LAS EXCEPCIONES

� Podemos ver una nueva entrada con el valor 8000 0180 en el multiplexor que proporciona el nuevo PC; un registro de causa, para guardar el motivo de la excepción y un registro de PC de la excepción, para guardar la dirección de la instrucción que a provocado la excepción. “La entrada 8000 0180 al multiplexor es la dirección inicial donde se debe empezar la búsqueda de instrucciones cuando ocurre una excepción.” A pesar de que no se muestra la señal de desbordamiento de la ALU es una entrada de control.

PROPIEDADES DE LAS EXCEPCIONES

� Excepciones que vuelven a comenzar� El segmentador puede tirar la instrucción

� El administrador se ejecuta, entonces regresa a la instrucción� Vuelve a buscar y se ejecuta desde lo eliminado

� El CP se guarda en el registro EPC� Se identifica la instrucción causante

EJEMPLO DE EXCEPCIÓN

� Excepción sobre add en

40 sub $11, $2, $444 and $12, $2, $548 or $13, $2, $64C add $1, $2, $150 slt $15, $6, $754 lw $16, 50($7)…

� Administrador80000180 sw $25, 1000($0)80000184 sw $26, 1004($0)…

EJEMPLO DE EXCEPCIÓN

EJEMPLO DE EXCEPCIÓN

LA CIRCUITERÍA

� «La máquina y el sistema operativo deben trabajar conjuntamente para que la excepciones se comporten tal como se espera»

� La tarea de la circuitería es normalmente parar la instrucción que causa la excepción en el medio de flujo de instrucciones:� dejando que las anteriores se completen

� eliminar todas la instrucciones posteriores

� activar un registro para mostrar la causa de la excepción

� salvar la dirección de la instrucción que la ha provocado

� saltar a una dirección predefinida

EL SISTEMA OPERATIVO

� El sistema operativo debe considerar la causa de la excepción y actuar en consecuencia.

� Para el caso de una instrucción no definida, mal funcionamiento de la circuitería o una excepción por desbordamiento, el sistema operativo normalmente detiene la ejecución del programa y devuelve un indicador de la razón

� Para una petición de un dispositivo de E/S o una llamada a una rutina de servicio del sistema operativo, este salva el estado del programa, realiza la tarea deseada y entonces reanuda la ejecución del programa

6.9PIPELINING AVANZADO: EXTRAYENDO MAYOR DESEMPEÑO

PARALELISMO A NIVEL DE INSTRUCCIONES (ILP)

� Segmentado: ejecutar múltiples instrucciones en paralelo.

� Para incrementar el ILP:� Segmentado profundo

� Menos trabajo por etapa => ciclos de reloj mas cortos

� Múltiples casos

� Etapas de segmentado replicadas => múltiples segmentados

� Comenzar múltiples instrucciones por ciclo de reloj

MÚLTIPLES CASOS

� Casos múltiples estáticos: es un enfoque para implementar un procesador multitarea cuando las decisiones las toma el compilador antes de la ejecución.

� Compilar grupos de instrucciones para ser tomadas juntas en cuenta

� Empaquetarlos en “ranuras por casos”

� El compilador las detecta y evita peligros

� Casos múltiples dinámicos: es un enfoque para implementar un procesador multitarea donde las decisiones las toma el procesador durante la ejecución.

� El CPU examina la trama de instrucciones para separar cada caso por ciclo

� El compilador puede ayudar a reordenar las instrucciones

� El CPU resuelve peligros utilizando técnicas avanzadas en tiempo de ejecución

ESPECULACIÓN

� “Adivinar” que hacer con una instrucción� Comenzar la operación lo mas pronto posible

� Comprobar si lo adivinado fue correcto

� Completar la operación si fue correcto

� Si no, volver atrás y hacer la operación correcta

� Común a los casos múltiples estáticos y dinámicos

ESPECULACIÓN DEL COMPILADOR/HARDWARE

� El compilador puede reordenar las instrucciones� Puede incluir instrucciones de reparación para recuperarse de

decisiones incorrectas

� El hardware puede mirar adelante para instrucciones a ejecutar� Almacenar los resultados en un buffer hasta que determine que

son necesitados

� Limpiar los buffer en caso de especulación incorrecta

ESPECULACIÓN Y EXCEPCIONES

� Y, ¿si ocurriera una excepción en una instrucción ejecutada especulativamente?

� Ej.: carga especulativa antes de comprobar un puntero a null

� Especulación estática

� Puede añadir soporte ISA (Industry Standard Architecture) para diferir las excepciones

� Especulación dinámica

� Puede almacenar las excepciones en un buffer hasta que se complete la instrucción (lo que puede no ocurrir)

CASOS MÚLTIPLES ESTÁTICOS

� El compilador agrupa instrucciones dentro de “paquetes de casos”� Grupos de instrucciones que pueden ser resueltas en un mismo

ciclo

� Determinados por los recursos de pipeline requeridos

� Pensar que un paquete de caso es una muy larga instrucción� Especifica operaciones concurrentes múltiples

� => palabra de instrucción muy larga: Very Long Instruction Word (VLIW)

CRONOGRAMANDO LOS CASOS MÚLTIPLES ESTÁTICOS

� El compilador debe remover la mayoría o todos los peligros� Reordenar instrucciones dentro de paquetes de casos

� No existen dependencias con un paquete

� Posiblemente haya dependencias entre algunos paquetes

CASOS MÚLTIPLES DINÁMICOS

� En procesadores llamados “superescalares”

� El CPU decide si emitir 0,1 o más instrucciones cada ciclo� Se evitan los peligros de datos y estructurales

� Se evita la necesidad de que el compilador cronograme� Aun así, todavía puede ayudar

� La semántica del código es asegurada por el CPU

CONCLUSIONES

CONCLUSIONES

� Poner burbujas en un PIPELINE es, en muchos casos, necesario aunque afecta al rendimiento.

� Mejorar rendimiento en derivaciones de procesos básicamente para un mejor manejo.

� El manejo de excepciones tiene que trabajar conjuntamente entre la maquina y el sistema operativo, para que se comporte tal como se espera.

� Existen dos tipos de pipelining avanzados:

� Casos multiples estático

� Casos múltiples dinámico

Los dos tipos son muy utilizados, pero el que se impone es el estático.