Transcript ppt - Universidad de Sonora

Pipelining
Peligros (hazards)
Peligros (hazards)
 Eventos que evitan que la siguiente instrucción se
ejecute en el siguiente ciclo de reloj.
Estructurales.
 Motivo: conflictos de recursos.
 Solución: duplicación de recursos.
Datos.
 Motivo: dependencias entre instrucciones.
 Soluciones: forwarding (bypassing) y reordenamiento
de instrucciones.
Universidad de Sonora
Arquitectura de Computadoras
2
Peligros (hazards)
Control (brincos).
 Motivo: en un brinco no se conoce la siguiente
instrucción hasta que la instrucción de brinco sale del
pipeline.
 Soluciones: detener (stall) el pipeline, especular
(adivinar) la siguiente instrucción y decisión retrasada
(delayed decision).
Universidad de Sonora
Arquitectura de Computadoras
3
Peligros estructurales
 Motivo: conflicto de recursos.
 Solución: duplicar recursos.
 Ejemplo: IF e ID necesitan acceso a la memoria.
 Solución: separar la memoria de instrucciones y la
memoria de datos.
 Ejemplo: IF y MEM necesitan acceso al PC.
 Solución: tener 2 copias del PC. Un PC apunta a la
siguiente instrucción y otro a la instrucción que está
siendo ejecutada.
Universidad de Sonora
Arquitectura de Computadoras
4
Peligros de datos
 Consecuencia: una instrucción, B, en el pipeline
debe esperar a que otra instrucción, A, termine.
 Conocido como peligro RAW (read-after-write).
 Motivo: B depende de A.
 Ejemplo:
A: add $s0, $t0, $t1
B: sub $t2, $s0, $t3
; s0 = t0 + t1
; t2 = s0 - t3
 Hay una dependencia de datos, también conocida
como dependencia de datos verdadera.
Universidad de Sonora
Arquitectura de Computadoras
5
Peligros de datos
 B necesita el valor de s0 en la etapa EX.
 A no escribe s0 hasta la etapa WB.
Universidad de Sonora
Arquitectura de Computadoras
6
Peligros de datos

Soluciones:
1. Detener (stall) el pipeline. B no comienza hasta
que A termine.
2. Forwarding (bypassing). Conectar por hardware las
etapas del pipeline.
Universidad de Sonora
Arquitectura de Computadoras
7
Peligros de datos
 Forwarding no soluciona todos los peligros RAW.
 Ejemplo:
A: lw $s0, 20($t1)
; s0 = Mem[t1 + 20]
B: sub $t2, $s0, $t3 ; t2 = s0 - t3
 s0 se calcula en la etapa MEM de A.
 Ya es tarde para hacer un forwarding a la etapa EX
de B.
 El pipeline se detiene (stall) un ciclo.
Universidad de Sonora
Arquitectura de Computadoras
8
Peligros de datos
 Forwarding no resuelve los peligros RAW cuando
una instrucción tipo-R sigue a una instrucción de
acceso a memoria (lw/sw).
Universidad de Sonora
Arquitectura de Computadoras
9
Peligros de datos
3. Reordenar instrucciones.

El sentido del programa no debe cambiar.
 Ejemplo:
A: lw $s0, 20($t1) ; s0 = Mem[t1 + 20]
B: sub $t2, $s0, $t3 ; t2 = s0 - t3

Solución:
A: lw $s0, 20($t1) ; s0 = Mem[t1 + 20]
C: lw $t4, 8($a0)
; t4 = Mem[a0 + 8]
B: sub $t2, $s0, $t3 ; t2 = s0 - t3
Universidad de Sonora
Arquitectura de Computadoras
10
Ejemplo
 Encontrar las dependencias en el siguiente código y
reordenar las instrucciones para evitarlas.
 Código en C/Java
A=B+E
C=B+F
Universidad de Sonora
Arquitectura de Computadoras
11
Ejemplo
 Código MIPS
 Asumiendo que B está apuntada por t0, E por t0+4,
F por t0+8, A por t0+12 y C por t0+16.
1. lw $t1, 0($t0)
2. lw $t2, 4($t0)
3. add $t3, $t1, $t2
4. sw $t3, 12($t0)
5. lw $t4, 8($t0)
6. add $t5, $t1, $t4
7. sw $t5, 16($t0)
Universidad de Sonora
; t1 = Mem[t0]
; t2 = Mem[t0+4]
; t3 = t1 + t2
; Mem[t0+12] = t3
; t4 = Mem[t0+8]
; t5 = t1 + t4
; Mem[t0+16] = t5
Arquitectura de Computadoras
12
Ejemplo

a)
b)
c)
d)
e)

Dependencias de datos:
1 y 3.
2 y 3.
3 y 4.
5y6
6y7
Forwarding (bypassing) elimina todas las
dependencias excepto b) y d).
Universidad de Sonora
Arquitectura de Computadoras
13
Ejemplo
 Las dependencias b) y d) se resuelven moviendo la
instrucción 5 hacia arriba:
1. lw $t1, 0($t0)
2. lw $t2, 4($t0)
5. lw $t4, 8($t0)
3. add $t3, $t1, $t2
4. sw $t3, 12($t0)
6. add $t5, $t1, $t4
7. sw $t5, 16($t0)
Universidad de Sonora
; t1 = Mem[t0
; t2 = Mem[t0+4]
; t4 = Mem[t0+8]
; t3 = t1 + t2
; Mem[t0+12] = t3
; t5 = t1 + t4
; Mem[t0+16] = t5
Arquitectura de Computadoras
14
Peligros de control

También llamados peligros de brincos.
 No se sabe que instrucción sigue a un brinco.
 Ejemplo:
beq $t0, $t1, etiqueta
instrucción_1
…
etiqueta:
instrucción_2
Universidad de Sonora
Arquitectura de Computadoras
15
 3 instrucciones comienzan antes de saber que debe brincar.
Universidad de Sonora
Arquitectura de Computadoras
16
Peligros de control

Soluciones:
1. Detener (stall) el pipeline hasta que el brinco
termine su etapa MEM. Muy lento
2. Reducir el retraso.
Usar hardware extra para que el PC se conozca al
final de la etapa ID.
Universidad de Sonora
Arquitectura de Computadoras
17
Peligros de control
 Ventajas de la solución 2:
 El pipeline se detiene 1 ciclo
Universidad de Sonora
Arquitectura de Computadoras
18
Peligros de control

Desventajas de la solución 2:
a) Hardware extra en la etapa ID: unidad de
comparación, sumador para el PC y bypass al
siguiente ciclo (incluyendo lógica extra para su
manejo).
b) Se generan nuevos peligros de datos: si la
instrucción anterior escribe uno de los operandos
se tiene que detener el pipeline.
Universidad de Sonora
Arquitectura de Computadoras
19
Costo de detener el pipeline
 Según SPECint2000:
 El 13% de las instrucciones son brincos.
 El CPI de las instrucciones es 1.
 Como los brincos tardan un ciclo extra, el CPI se
incrementa a 1.13.
 Si no se cuenta con hardware extra, el PC se
conoce al final de la etapa MEM y el pipeline se
detiene tres ciclos por cada brinco.
 Conclusión: detener el pipeline no es práctico.
Universidad de Sonora
Arquitectura de Computadoras
20
Peligros de control
3. Predecir que todos los brincos son no tomados.

Si se acierta, el pipeline continúa a toda velocidad.
 Si no se acierta, es necesario deshacer lo que se
haya hecho.
 Problema: se necesita hardware extra para limpiar
(flush) el pipeline.
Universidad de Sonora
Arquitectura de Computadoras
21
Peligros de control
 Brinco no tomado (acierto)
Universidad de Sonora
Arquitectura de Computadoras
22
Peligros de control
 Brinco tomado (no acierto)
Universidad de Sonora
Arquitectura de Computadoras
23
Peligros de control
4. Especulación (adivinar) la siguiente instrucción.

Si se acierta, el pipeline continúa a toda velocidad.
 Si no se acierta, es necesario deshacer lo que se
haya hecho.
Universidad de Sonora
Arquitectura de Computadoras
24
Peligros de control
a) Usar criterios estáticos. Por ejemplo, asumir que
todos los brincos hacia arriba son parte de un ciclo
y marcarlos siempre como tomados.
b) Criterios dinámicos. Llevar una historia reciente de
cada brinco.
Algunos algoritmos dinámicos aciertan hasta el
90% de veces.
Universidad de Sonora
Arquitectura de Computadoras
25
Peligros de control
5. Decisión retrasada (delayed decision)

Usada en MIPS.
 La siguiente instrucción a un brinco se ejecuta
siempre.
 El ensamblador coloca después de la instrucción
de brinco alguna instrucción que no sea afectada
por el brinco.
 Hay 3 formas de escoger la instrucción.
Universidad de Sonora
Arquitectura de Computadoras
26
Peligros de control
Universidad de Sonora
Arquitectura de Computadoras
27
Peligros de control
 La opción (a) es la preferida.
 Las opciones (b) y (c) se usan si (a) no es posible.
 La opción (b) es conveniente en brincos que son
tomados con alta probabilidad, como en ciclos.
 La instrucción que se usa en (b) y (c) debe ser una
que no afecte el sentido del programa si el brinco va
en sentido contrario.
Universidad de Sonora
Arquitectura de Computadoras
28
Peligros de control
 Ejemplo:
add $a0, $a1, $a2
beq $at, $v0, Etiqueta
lw $v1, 300($zero)
 Como la suma no depende del brinco se reordena a:
beq $at, $v0, Etiqueta
add $a0, $a1, $a2
lw $v1, 300($zero)
Universidad de Sonora
Arquitectura de Computadoras
29
Resumen
Pipelining:
 Explota el paralelismo entre instrucciones en un flujo
secuencial.
 Incrementa el número de instrucciones que se
ejecutan simultáneamente.
 Incrementa la tasa (rate) a la cual las instrucciones
comienzan y son ejecutadas.
 No reduce la latencia, el tiempo que de ejecución de
una instrucción individual.
Universidad de Sonora
Arquitectura de Computadoras
30
Resumen
 Mejora el throughput, la cantidad de trabajo hecha
por unidad de tiempo.
 Existen peligros (hazards) estructurales, de datos y
de control.
 Parar (stall) el pipeline, predicción de brincos y
forwarding ayudan a resolver los peligros.
Universidad de Sonora
Arquitectura de Computadoras
31