Tema 3. Arquitectura Del Core - Planificacion de Instrucciones - Soluciones PDF

TEMA 3.
Arquitectura del core:

planificación de instrucciones
©Julio Sahuquillo
Contenido
1.  Introducción
2.  Ventana de instrucciones distribuida
3.  Ventana de instrucciones centralizada
4.  Complejidad etapa de issue
5.  Ejecución de instrucciones de acceso a memoria
6.  Desambiguación
7.  Ejecución en orden
8.  Load forwarding y load bypassing
9.  Desambiguación parcial
10.  Caso de estudio
•  Bibliografía
–  Jean-Loup Baer
Microprocessor Microarchitecture, Cambridge 2010
–  J.P. Shen, and M.H. Lipasti,
Modern Processor Design: Fundamentals of Superscalar Processors,
McGraw Hill 2005
–  J. Smith, and G. Sohi
The Microarchitecture of Superscalar Processors
Proceedings of the IEEE, December, 1995
–  Alpha 21264 Microprocessor Hardware Reference Manual
–  R10000 Microprocessor User Manual
©Julio Sahuquillo -2-

1. Introducción
•  Estaciones de reserva
–  Tras decodificar una instrucción se prepara una ER para su ejecución,
donde están hasta que no haya dependencias y
el operador requerido se encuentre libre.
•  Ventana de instrucciones
–  Conjunto de instrucciones ya decodificadas entre las que deben
resolverse las dependencias
•  Implementación de la ventana de instrucciones

–  Distribuida: ER distribuidas en los operadores
–  Centralizada: 1 conjunto único de ER
•  Según la implementación variará

la complejidad hardware y las prestaciones
1. Introducción: lógica de lanzamiento

•  La lógica de lanzamiento (issue)
–  Lanza las instrucciones desde estaciones de reserva al operador
•  Una de las más complejas del procesador
–  Funciones que implementa
•  1. Identificar entradas con instrucciones listas
•  2. Si hay varias, seleccionar una para lanzar (issue)
•  3. Lanzar
•  4. Liberar entrada de la ER
–  Una entrada se libera cuando se lanza la instrucción
Destino Operando 1 Operando 2

Tag Busy Op Ready Tag Contents Ready Tag Contents
# rob Rj Qj Vj Rk Qk Vk

2. Ventana de instrucciones distribuida
•  Ventajas implementación distribuida
–  Pocas entradas asociadas a cada operador ! simplifica la lógica
–  Sólo las ER de loads y stores son grandes, pero se
lanzan en orden ! sólo se examina una instrucción
–  Si se libera una entrada por ciclo ! lógica de liberación simple
•  Inconvenientes
–  Pueden bloquearse el dispatch por falta de ER en un operador
aunque en otro operador haya entradas libres
–  Hay que replicar la lógica en cada operador
•  Aspectos de diseño
–  Número de entradas en las estaciones por operador
–  Análisis del impacto de una lógica simple (FIFO) en las prestaciones
Destino Operando 1 Operando 2

Tag Busy Op Ready Tag Contents Ready Tag Contents
# rob Rj Qj Vj Rk Qk Vk
Ventana distribuida: número de entradas

•  Problemática: el dispatch se bloquea si no hay ER libres tras renombrar la
instrucción
–  Si se encuentran distribuidas el aprovechamiento de entradas es peor
que si están en una misma estructura
–  ¿Cuántas hacen falta por operador?
•  Sistema base:
–  ROB de 16 entradas
–  ALU enteros 4 entradas
–  Unidad de saltos 4 entradas
–  Unidad de almacenamiento 8 entradas
–  Unidad de carga 8 entradas
–  Sumador de c.f. 2 entradas
–  Multiplicador de c.f. 4 entradas
•  Planificación de loads y stores en orden.

•  Para simplificar el análisis se asume que todas las ER
tienen el mismo nº de entradas

Ventana distribuida: número de entradas
•  Los resultados para un decoder de 4 instrucciones no son mucho mejores
debido a la limitación de la etapa de fetch
•  Las prestaciones se reducen mucho cuando pasamos de 8 a 4
–  Causa principal: reducción de los buffers de stores
Efecto del nº de entradas en cada ER (por operador)
Ventana distribuida: impacto lógica simple

•  Lógica simple: para simplificar la lógica las ER pueden lanzar
instrucciones en el orden de llegada
–  Lógica FCFS es simple porque sólo se examina una entrada por operador
–  Loads, stores y saltos ya operan en orden
–  ¿Impacto de gestionar el resto de ER como colas FCFS?
•  Apenas se pierde: 6% en decoder de 2 inst. y 2% en decoder de 4 inst.
•  Motivo: hay cierto orden secuencial en el código; cuando una dependencia impide
el lanzamiento en un operador, es más importante lanzar instrucciones a otro
operador que lanzar una nueva al operador bloqueado
2 inst. decoder 4 inst. decoder
Lanzamiento FCFS versus out-of-order

3. Ventana de Instrucciones Centralizada
ROB B. Registros
Cache de
Instrucciones
Decoder
Código Vj Qj Vk Qk
Los campos variarán
según implementación
Bus de
operandos
Loads Stores
Cache de
Datos
Bus común
Implementación
•  Ventajas:
–  Gestiona peticiones para todos los operadores y necesita menos ER
que una distribuida
•  Inconvenientes:
–  Concentra toda la lógica de lanzamiento ! lógica más compleja
•  Debe seleccionar entre más instrucciones
•  Debe seleccionar más instrucciones: una para cada operador
•  Puede liberar más de una entrada por ciclo
! lógica de asignación y liberación de entradas más compleja
•  Una entrada puede ubicar instrucciones de cualquier tipo
•  Implementaciones
–  La pila de dispatch de Torng
–  El RUU de Sohi and Vajapeyan
–  Cola de instrucciones + ROB

Implementación 1: Pila de dispatch
•  Cada ciclo
–  1. Identificar instrucciones listas para lanzarse
–  2. Seleccionar instrucciones ! establecer prioridades
–  3. Lanzar instrucciones
–  4. Liberar las entradas de la pila
–  5. Colapsar: quitar los huecos de en medio
•  Las instrucciones no lanzadas se quedan en la pila en orden de

programa ! lógica de dependencias correcta
•  Fácil de encontrar la más antigua ! facilita mecanismo de
prioridades
•  Tras colapsar los huecos se quedan arriba
•  Las instrucciones decodificadas se colocan en la cima de la pila
Ejemplo
ANTES DE LANZAR DESPUÉS DE LANZAR
Decodificador Decodificador
i11 --
i10 --
i9 --
i8 --
Pila de dispatch Pila de dispatch

i7 i11
i6 issue i10
i5 i9
i4 i8
i3 issue i7
i2 issue i5
i1 i4
i0 issue i1

Prestaciones
•  Prestaciones
–  Hipótesis: ROB de 16 entradas
•  Las mejores prestaciones se obtienen con una pila de 8 entradas
–  Para obtener las mismas prestaciones con ER distribuidas hacen falta
32 (doble que el ROB)
4 veces más entradas!!!
Efecto del tamaño de la pila de dispatch
Pila de dispatch vs ventana distribuida

–  Ventajas de la pila
•  Requiere menos área
–  4 veces menos entradas y lógica de anticipación (comparadores y
cortocircuitos)
•  La lógica de lanzamiento no se replica excepto para enteros y reales.
Con ER se replica tantas veces como tipos de operadores, puede llegar
a ser del orden de 10
–  Inconvenientes
•  Lógica de lanzamiento es más compleja porque la pila mantiene las
instrucciones en orden
•  La lógica de compresión es compleja
–  Una entrada puede recibir instrucciones de cualquier otra entrada y
del decodificador
•  Por ejemplo en una ventana de 8 instrucciones y decoder de 4
! los datos pueden venir como máximo de 11 posibles sitios
–  La lógica de compresión se encuentra en el camino crítico
•  Pasos: lanzar, colapsar y almacenar nuevas instrucciones
•  El decodificador no puede poner instrucciones hasta que no se
colapse la pila
Implementación 2: ROB + cola de instrucciones
•  La complejidad de la pila de dispatch se debe a que mantiene las
instrucciones en orden
•  ROB + cola de instrucciones (ventana central)

–  ROB
•  Mantiene el orden de las instrucciones
•  No se comprime, la liberación de entradas no se encuentra en el
camino crítico
•  Entradas se asignan tras el decode y se liberan en el commit
–  Ventana central
•  No necesita mantener el orden
•  Ejemplo de heurística de lanzamiento
–  Lanzar instrucciones utilizando su posición en la ventana
–  Si no se guarda más información, no se conoce el orden del
programa
ROB + ventana central
ANTES DE LANZAR DESPUÉS DE LANZAR
Decodificador Decodificador
i11 --
i10 --
i9 --
i8 --
Cola de issue Cola de issue (ventana central)

i7 i7
i6 issue i11
i5 i5
i4 i4
i3 issue i10
i2 issue i9
i1 i1
i0 issue i8
•  Prestaciones con lanzamiento basándose en la posición de la ventana

–  Sobre un 1% menos que la pila de dispatch !
las dependencias entre instrucciones son suficiente para establecer la
prioridad de lanzamiento
4. Complejidad etapa de issue
•  Contenido estaciones de reserva (ventana central o distribuida)
–  Almacena datos:
•  Modelo estudiado AIC. Los datos se almacenan en la ER para
ejecutar la instrucción. Implementación compleja
•  Se precisa un bus de anticipación y otro de etiquetas por cada
instrucción que hace el WB
•  Cuando una instrucción hace WB se comparan la etiquetas y si hay
acierto, se pone a 1el bit ready de los operandos
•  Si ambos operandos están a 1 se pone a 1 el bit ready de la
instrucción = wakeup
dispatch forwarding dispatch forwarding
slots buses slots buses
… … … …
Destino
Registro Busy Op Ready Tag Contents Ready Tag Contents Ready
= =
Bus de etiquetas

–  No almacena datos: implementación más sencilla
•  Los datos solo se almacenan en el banco (ni en el ROB ni en las ER)
–  Cuando se decodifica se pone en la ER el registro como marca
–  Cuando el valor disponible en el banco, y el operador libre, se lanza (la
primera tarea tras lanzar es leer los operandos en el banco
–  No hay buses de forwarding
•  Se utiliza menos espacio
•  Implementación actual típica
–  La cola que implementa la ventana se denomina cola de instrucciones o
IQ (instruction queue)
Destino
Registro Busy Op Ready Tag Ready Tag Ready
= =
Bus de etiquetas

•  Lógica de asignación y liberación de entradas en la IQ
–  Asignación: se puede implementar con un codificador prioritario
–  La lógica de issue implementa alguna heurística de selección
Dispatching
Lógica de Lógica de issue
asignación
Busy Ready
Issuing

•  3 pasos
–  Wakeup: esperar a que las instrucciones hagan WB en dicho ciclo
•  Se actualizan dependencias
•  Poner el bit de lista a 1 (si operandos preparados)
–  Selección
•  Elegir instrucciones del conjunto de instrucciones listas
•  Políticas de selección
–  Primero la más antigua
–  Primero la de más alta latencia (R10000)
–  Basada en su posición en la ventana (PA8000)
–  Lanzamiento: cuando se lanzan se leen los operandos en los registros
T wakeup T selección T lanzamiento

Ejercicio
•  Características procesador
–  Etapas
•  IF, ID, D (renombrado y dispatch), I, En ejecución, WB, C
–  Unidad de carga. Latencia=2 IR=1/2
–  Suma/resta. Latencia=2 IR=1
–  Mult/div. Latencia=3 IR=1
•  Se pide
–  Realice el diagrama de instrucción/tiempo del siguiente código
–  Indique cuantas instrucciones hay como máximo en la cola de instrucciones y en
qué ciclo
–  Indique en qué ciclo lee la MULT.D sus 2 operandos
! ! 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 !
L.D F6,32(R2) IF! ID D I L1 L2 WB C!
L.D F2,48(R2) IF!ID D i I L1 L2 WB C!
MULT.D F0,F2,F6 !
IF ID D i i i I M1 M2 M3 WB C!
ADD.D F8,F6,F10!
F8,F6,F10 IF ID D I A1 A2 WB - - - - C !
ADD.D F4,F10,F10!
F4,F10,F10 IF ID D I A1 A2 WB - - - - C !
!
Contenido
1.  Introducción
2.  Ventana de instrucciones distribuida
3.  Ventana de instrucciones centralizada
4.  Complejidad etapa de issue
5.  Ejecución de instrucciones de acceso a memoria
6.  Desambiguación
7.  Ejecución en orden
8.  Load forwarding y load bypassing
9.  Desambiguación parcial
10.  Caso de estudio

5. Ejecución de loads/stores
ROB B. Registros
Cache de
Instrucciones
Decoder
Cola de Instrucciones
Bus de
operandos
Loads Stores
Cache de
Datos
Bus común
©Julio Sahuquillo 23
Repaso ejecución
–  Etapas: IF, ID, Rn, I, En ejecución, WB, C
–  Unidad de carga/alm. Latencia=2 IR=1/2
•  Se pide
–  Realiza el diagrama de instrucción/tiempo del siguiente código asumiendo que en
I se pone la dirección de la instrucción de acceso a memoria en los buffers
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
L.D F6,32(R2) IF ID Rn I L1 L2 WB C
L.D F2,48(R2) IF ID Rn - I L1 L2 WB C
MULT.D F0,F2,F6 IF ID Rn - - - I M1 M2 M3 WB C
S.D F6,60(R4) IF ID Rn - - - - - - - - C L1 L2
ADD.D F8,F6,F10 IF ID Rn I A1 A2 WB - - - - C
ADD.D F4,F10,F10 IF ID Rn I A1 A2 WB - - - - C
¿Qué pasaría si la segunda o la primera load fallasen en L1?

¿Cómo afectaría a las prestaciones?
En caso de conflicto estructural, ¿debe tener prioridad una load o una store?
Cadenas de dependencia
•  Existen largas cadenas de instrucciones dependientes de las loads

! necesidad de tratamiento eficiente
•  Fallos en L2:
–  Alta latencia ! las instrucciones dependientes no avanzan
! se llena el ROB y/o la IQ
! se bloquea el dispatch
–  Cuello de botella en las prestaciones de los “cores” de los procesadores
actuales
Cálculo de dirección y acceso a memoria
•  Fases en la ejecución de una instrucciones de acceso a memoria:

–  1. Cálculo dirección
•  Se suele utilizar una unidad de cálculo de direcciones
–  2. Traducción de dirección
•  TLB
–  3. Acceso memoria (jerarquía)
•  Se accede a L1
–  si falla a L2
•  si falla a …
•  Muchos procesadores dividen la instrucción internamente en 2:

–  Cálculo de dirección (paso 1): en dispatch prepara IQ y ROB
–  Acceso a memoria (pasos 2 y 3): en dispatch prepara LSQ y ROB
•  Los pasos 2 y 3 se suelen realizar en paralelo

–  Las etiquetas leídas de la cache se comparan con el resultado de la TLB
Ejecución instrucción: etapas
•  Dispatch
–  Se prepara una entrada en el ROB y otra en la LSQ
•  Issue, ejecución y WB
–  Instrucción encargada del cálculo de la dirección:
•  Se lanza, ejecuta y hace WB como las instrucciones aritméticas
•  Se lanza cuando tiene los operandos y el operador preparados
–  Loads
•  Se puede lanzar cuando la dirección está lista
SI NO hay dependencias con stores previas
•  Commit
–  Stores: acceso a la cache tras el commit (no tienen etapa de issue)
•  Recover: se activa si hay fallo de especulación
–  Recover on commit
•  Se liberan todas las entradas del ROB y de la LSQ,
excepto stores confirmadas (stores pendientes)‫‏‬
–  Recover en writeback
Se liberan las correspondientes entradas del ROB y sus asociadas en la LSQ
6. Desambiguación: el problema
–  Etapas: IF, ID, Rn, I, En ejecución, WB, C
–  Unidad de carga. Latencia=2 IR=1
•  Diagrama de instrucción/tiempo
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
S.D F6,60(R4) IF ID Rn - - - - C L1 L2
L.D F2,48(R2) IF ID Rn ¿Memoria libre, ¿puedo acceder?
MULT.D F0,F2,F6 IF ID Rn …
Desambiguación: el problema
•  El orden de las loads/stores en el acceso a memoria se puede alterar
si se respetan las dependencias
•  Tipos de dependencias:
sw X
RAW
lw X WAW
WAR
sw X
•  Desambiguar: averiguar si hay dependencias o alias

(acceso a la misma dirección)
•  ¿Cuándo desambiguar?
–  Se necesita conocer la dirección ! No se puede resolver en ID, Rn, o
dispatch
•  No sirve el renombrado
•  Las técnicas deben mantener las dependencias de datos de memoria
para respetar la semántica del programa
•  Esquemas de desambiguación
–  Orden total de loads y stores
–  Orden de loads / Orden de stores
–  Orden Parcial
–  Desambigüación especulativa
7. Ejecución en orden de loads/stores
•  Orden total de loads y stores

–  Todas las instrucciones de acceso a memoria se ejecutan en orden
–  Fácil de implementar con 1 única cola de loads/stores,
donde todas las loads y stores reservan una entrada en la cola
tras el renombrado (en el dispatch)
–  La lógica de lanzamiento elige la instrucción más antigua (load o store)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
S.D F6,60(R4) IF ID Rn - - - - C L1 L2
L.D F2,48(R2) IF ID Rn - - - - I L1 L2 WB C
MULT.D F0,F2,F6 IF ID Rn - - - - - - I M1
–  Suficiente pero no necesaria

–  Conservativa e impone serias limitaciones de prestaciones
–  Ningún procesador la implementa
Ejemplo limitación prestaciones

Y(i) = A ⋅ X(i) + Y(i)
ld F0, A
addi R4, Rx, 512 ; 512 = 8 x 64
ld X ld Y
Bucle: ld F2, 0(Rx)

muld
mul.d F2, F0, F2 ; A⋅X(i)
ld F4, 0(Ry)
add.d F4, F2, F4 ; A⋅X(i)+Y(i) add.d
sd F4, 0(Ry)
addi Rx, Rx, # 8
addi Ry, Ry, # 8 sd Y
sub R4, R4, Rx ; última dirección?
bnz R4, bucle
•  No existen dependencias de datos entre iteraciones distintas

–  Las dependencias verdaderas se encuentran en una misma iteración
–  Todas las iteraciones pueden ejecutarse en paralelo
•  Si las loads/stores se ejecutan en orden, la primera load de una iteración no
puede acceder a la cache/memoria hasta que no acabe la store de la
iteración previa
Adelantamiento de loads
–  Las loads se encuentran en el camino crítico

•  Reducir u ocultar su latencia es importante para las prestaciones
•  Es importante adelantar su ejecución
•  Todas los procesadores (los tipos de desambiguación excepto el
primero) implementan esquemas para que las loads pueden adelantar
a las stores en el acceso a la cache
–  Desambigüación: Orden de loads / Orden de stores
•  Las loads y las stores se ejecutan en orden entre ellas
pero hay ejecución o-o-o entre loads y stores
! Las loads pueden adelantar a las stores
•  Ej. AMD K6
–  Desambigüación: Orden Parcial
•  Las loads se ejecutan o-o-o entre ellas
si las direcciones de todas las stores previas son conocidas
•  Las stores se ejecutan en orden
•  Ej. R10000, AMD K8
8. Load bypassing y load forwarding
•  Esquemas de adelantamiento de loads

–  Concepto: load bypassing y load fordwarding
•  Load bypassing
–  La load adelanta a la store en el acceso a la cache si
dirección load ≠ dirección stores previas
(no hay dependencias RAW )
Store X
Store y
…
Load Z
8. Load bypassing y load forwarding
•  Load forwarding
–  Si dirección load = dirección alguna store previa
(dependencia RAW)
! la store anticipa el dato a la load desde la cola
! la load no realiza el acceso a cache/memoria
Store X
Store y
Load X
©Julio Sahuquillo
Cola de loads y cola de stores

•  Microprocesadores modernos
–  La LSQ se implementa en 2 colas separadas: load queue LQ y store queue SQ
–  El acceso de la store se confirma en commit.
Se libera la entrada del ROB pero no la de la SQ
–  Con load bypassing una store confirmada, puede retrasar mucho
su acceso a la cache
•  Estados de una store tras el dispatch
–  Sin completar ! Completada ! retirada (del ROB) ! committed (esc. en cache)‫‏‬
•  Sin completar: dirección no resuelta o dato no disponible
•  Completada (writeback): dirección resuelta y dato escrito en el buffer
•  Confirmada o Retirada: confirmada su escritura pero esperando actualizar memoria
•  Buffer de stores
–  Se utiliza un puntero para separar las completadas o un bit de estado
–  Fallo de especulación: no se liberan las entradas de las retiradas
SQ
D cache
Committed
Completadas Retiradas
Load bypassing y load forwarding
•  Esquema base
SQ
dato Dato
Unidad
de stores
@ Al
Dato registro
Dirección
Unidad
de loads D cache
Load bypassing con SQ

•  Load bypassing:
–  Hay que comprobar que no hay dependencias con stores previas
–  Desambiguación: búsqueda asociativa de alias en el store buffer
•  Si no se encuentran alias
–  La load lee en la cache y se ejecuta normalmente
•  Si se encuentran
–  La load no debe ejecutarse
–  Debe relanzarse posteriormente ! las E.R. de las loads no se
pueden liberar en issue
SQ Acierto o no (relanzamiento)‫‏‬
Dato
Unidad
de stores
@ Dato
Al
registro
Comparación Direción
Unidad
de loads D cache
Load bypassing con SQ (cont)‫‏‬
•  Problema de load bypassing: complejidad búsqueda asociativa
–  Lentitud: su latencia debe ser menor que el acceso a la cache
•  Soluciones:
–  Solución 1: Reducir el tiempo con comparadores con un subconjunto de bits
•  Problema: pueden detectarse falsos alias ! la load espera a leer en la cache
por una store de la cuál no depende ! pérdida de prestaciones
–  Solución 2: Utilizar todos los bits en la comparación, pero acceder en paralelo al
buffer y a la cache
Acierto
-relanzamiento
-espera escritura en Mem
SQ Fallo
Completadas Retiradas -el dato leído de la cache
es correcto
Dato
Unidad
Al
de stores
@ registro
Dato
Unidad
de loads D cache
Load forwarding desde la SQ

•  Load forwarding o store-load forwarding:
–  Complementa la técnica de load bypassing
–  Misma lógica de búsqueda asociativa que bypassing
•  Si se detecta algún alias ! las loads leen el dato desde la SQ
•  Si no se detecta ! se utiliza el dato leido en la cache
–  Se requiere 1 puerto de lectura adicional en la SQ para leer el dato
–  Evita leer muchos datos de la cache
•  Menor presión sobre el ancho de banda del bus de la cache
SQ Match
Dato
Unidad 1
de stores
Al
@ Dato
0
registro
Unidad
de loads D cache
Load forwarding: complejidad y prestaciones
•  Load forwarding:
–  Lógica compleja
•  Múltiples alias ! se requiere lógica prioritaria para seleccionar del dato de la
store más joven
–  Prestaciones
•  Load bypassing: mejora de 11 a 19%
•  Load forwarding: añade 1 a 4%
Realiza el ejercicio anterior con bypassing

–  Sin bypassing (cache no segmentada)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
S.D F6,60(R4) IF ID Rn - - - - C L1 L2
L.D F2,48(R2) IF ID Rn - - - - - I L1 L2 WB C
MULT.D F0,F2,F6 IF ID Rn - - - - - - - I M1 …..
L.D F2,52(R2) IF ID Rn - - - - - I L1 L2
–  Con bypassing (asumiendo que las loads no dependen de

la store y que la dirección se pone en dispatch)
1 2 3 4 5 6 7 8 9 10 11 12
S.D F6,60(R4) IF ID Rn - - - - C - L1 L2
MULT.D F0,F2,F6 IF ID Rn - - I M1 . . .
L.D F2,52(R2) IF ID Rn I L1 L2
Caso de estudio: AMD K6
Orden de loads/Orden de stores
–  Esquemático AMD K6
Esquemático AMD K6
–  Load queue y store queue:
•  Almacenan las instrucciones (loads/stores) en orden.
•  Se reserva entrada tras el renombrado y permanecen hasta que son
las más viejas y tienen los operando listos.
–  Store buffer
•  Almacena la dirección y dato de las stores en orden hasta que son las
más viejas del procesador y pueden actualizar la memoria.
•  Las stores no esperan por el dato para hacer issue. El dato se lee en
la etapa de cálculo de la dirección, sino está se bloquea el pipeline de
las stores.
–  Etapa de desambiguación
•  Loads: comparan su dirección con
–  la de las stores más viejas que ella en el store buffer.
–  con la de la store que está calculando su dirección. Es una
comparación parcial porque no le da tiempo a calcularla toda.
–  Comprueba el planificador para asegurarse que no queda ninguna
store más vieja sin haber calculado su dirección.
–  El AMD K8 mejora esta implementación permitiendo que las loads
se adelanten entre ellas
9. Desambiguación especulativa
•  Desambiguación total (PESIMISTA)
–  No hay especulación
–  Cuando se accede a la SQ, las direcciones de las stores son todas
conocidas, sino la load no debe lanzarse (asumida hasta ahora)
•  Penalización de prestaciones
–  Ej. PowerPC 604
•  Desambiguación especulativa (OPTIMISTA)
–  Las loads acceden a memoria aunque haya stores con dirección
desconocida ! ejecución especulativa
–  Ej. Alpha 21264, Power 4, Itanium SQ
sw sw sw Operación
lw reg, M(100)
@
200 ? 300
4 dato
4 2
Desambiguación especulativa
–  Ejecución de la load
•  Busqueda asociativa en la SQ y acceso a la cache tan pronto como
haya un puerto libre
•  Si hay direcciones no resueltas ! las loads se guardan en un buffer
especial (finished load buffer) y se ejecutan especulativamente
•  Cuando una store llega a etapa commit
–  Búsqueda asociativa en el finished load buffer
–  Si acierto = fallo de especulación. Alguna load más joven que accede a la
misma dirección se ha ejecutado de manera especulativa
•  Debe cancelarse la ejecución de la load y las instrucciones
posteriores
Dato
Unidad Dato
1
Al
registro
de stores @ D cache
Dirección Dato
0
Unidad
de loads @
Acierto:
vaciar el ROB a partir de la load
dato
Loads
Desambiguación especulativa
•  Ejemplo de fallo de especulación

(asumimos que R10=R11)
Código Fuente Ejecución especulativa Relanzamiento
S.D R0, 0(R10) L.D R1, 0(R11)

.. .. L.D R1, 0(R11)
<Siguiente >
L.D R1, 0(R11) S.D R0, 0(R10)
...
<Siguiente + 1>
Caso de estudio: Alpha 21264

Desambigüación especulativa
–  Esquemático Alpha 21264
Esquemático Alpha 21264
–  Load/store queue
•  Las instrucciones esperan hasta que sus operandos fuente están
listos.
•  Las stores esperan tanto al registro para el cálculo de la dirección
como al dato.
–  Load queue y Store queue
•  Almacena las direcciones físicas de loads / direcciones físicas y datos
stores en orden, aunque en la cola entran o-o-o
•  Se reserva entrada tras el renombrado (en orden)
•  Las loads permanecen hasta que se retiran.
•  Las stores debe esperarse a la escritura en la cache.
•  Se implementa con una CAM de 32 entradas.
–  Wait queue
•  1024 entradas de 1 bit indexadas por PC
•  Cuando una load adelanta a una store más joven
! se genera una store-load trap
! se pone un 1 en la entrada de la tabla asociada al PC de la load
•  En posteriores ejecuciones de la load, si su entrada está a 1
! no se vuelve a lanzar especulativamente.
Esquemático Alpha 21264

–  Etapa de desambiguación
•  Stores: almacenan su dirección y dato en la store queue.
–  Comprueban si en la load queue se ha lanzado una load
más joven ! si ocurre, se lanza una “store-load violation
trap” y la ejecución se reanuda a partir de la load
Consistencia secuencial (concepto) “2 loads a la misma dirección

de memoria deben guardar el orden de acceso respecto a una
store a la misma dirección de otro procesador. Si la load más
joven obtiene el dato viejo, la load más vieja no puede obtener un
dato nuevo”. El problema surge con las invalidaciones y
actualizaciones de otro procesador … ¿Cómo se evita?
•  Loads: almacenan su dirección en la load queue.

–  Comparan su dirección con la de la loads más jóvenes,
si hay coincidencia
! se lanza una load-load memory violation trap
! y reanuda la ejecución desde la que ha disparado el trap.
Predicción de dependencias
–  Ejecución especulativa puede suponer beneficios de prestaciones
importantes
•  Anticipa fallos de cache ! oculta la latencia de memoria
•  Principal inconveniente
–  Sobrecarga que conlleva el recover
–  Aplicar técnicas de predicción de dependencias para reducir el número de
loads lanzadas especulativamente
–  Predicción de dependencias
•  Técnicas para determinar relaciones entre load y stores
•  En aplicaciones típicas es bastante predecible y se pueden utilizar predictores
simples
•  Ejemplos
–  Cambio simple
–  Tabla de predicción de load
–  Conjuntos de stores
–  LECTURAS
–  A. Moshovos, “A memory dependence prediction,” Phd Thesis, U. Wisconsin, 1998
–  G,Chrysos and J. Emer, “Memory dependence prediction using store sets,” Proc. of the ISCA 1998
–  ESQUEMA 1: cambio simple

•  Inicialmente, las loads especulan porque las dependencias
son poco frecuentes
•  Si se detecta una dependencia de una load
con una store previa
todas las instancias posteriores de la load esperarán
•  El cambio de especulativa a no especulativa
solo se hace una vez
•  Se puede utilizar un bit en la cache de instrucciones
•  Utilizado en el Alpha 21264
–  ESQUEMA 2: Tabla de predicción de load: utilizado en la arquitectura Intel Core
•  La LQ tiene 4 campos: etiqueta, dirección, spec y update

–  Spec se pone a 1 cuando se lanza especulativamente
–  Update se pone a 1 si se detecta relación store-load
•  Se utiliza una tabla auxiliar con contadores con saturación,

indexada por el PC de la load para
predecir si la load se lanza especulativamente
–  El bit de mayor peso del contador indica si se lanza especulativamente
•  1 se especula, 0 no se especula
–  Si la load se lanza especulativamente, se inicializa el campo spec=1
–  ESQUEMA 2: Tabla de predicción de load: (cont)
•  Cuando la store llega a la etapa etapa de commit

mira en la LQ si su dirección coincide con alguna load lanzada
–  Si coincide y spec=1 ! fallo de especulación, se aborta la load y
siguientes instrucciones
•  Se resetea el contador ! ctr=0 (estado strong nonspeculate)
–  Si coincide y spec=0 entonces se inicializa el campo update=1,
para indicar que se ha detectado una dependencia
•  Cuando una load llega a etapa de commit (no ha sido abortada)

–  Si spec=1
•  Especulación correcta ! Incrementar contador
–  Si spec=0
•  Si update=1 (se ha detectado una dependencia con una store previa)
se resetea el contador ! ctr=0 (estado strong nonspeculate)
para evitar que se especule
•  Si update=0 (no se ha detectado ninguna dependencia) entonces se
incrementa el contador ctr++ para especular en el futuro
Caso de estudio 3: IBM Power 4
•  Dispatch
–  Loads
•  Reservan una entrada en la LRQ (load reorder queue)
–  Stores
•  Reservan una entrada en la SRQ (store reorder queue)‫‏‬
•  Reservan una entrada en la SDQ (store data queue)‫‏‬
SRQ (32 entradas)

@
Dato SDQ
Dispatch
@
Nº Registro
especulativa
LRQ (32 entradas)
Caso de estudio 3: Power 4 (cont.)

•  Ejecución de loads
–  Buscan en la SRQ y en cache al mismo tiempo
–  Si hay acierto en la SRQ (load hit store) la store anticipa el dato
–  Si búsqueda en SRQ tarda más tiempo que el acceso a la cache
! la load se ejecuta especulativamente (se pone el bit esp. a 1)
SRQ (32 entradas)

@
Dato SDQ
Dispatch
@
Nº Registro
especulativa
LRQ (32 entradas)
•  Ejecución de loads (cont.)
–  Bit snoop: la LRQ incluye el bit snoop que la lógica del controlador pone a 1
cuando se produce un snoop (acción de coherencia) a la línea que contiene
el dato para dicha entrada.
–  Cuando la load se ejecuta, compara su dirección con las direcciones de la
LRQ. Si hay acierto con una load más joven (load hit load) que tiene el bit
snoop = 1 ! problema de consistencia secuencial y la load más joven debe
relanzarse.
SRQ (32 entradas)
@
Dato SDQ
Dispatch
@
Nº Registro
especulativa
LRQ (32 entradas)

•  Commit de stores
–  Cuando una store llega a commit busca en la LRQ
para ver si alguna load más joven se ha lanzado
especulativamente a la misma dirección (store hit load)
–  Si hay acierto, la load y las instrucciones posteriores se eliminan
del procesador y se relanzan
Dato
Dispatch
@
Nº Registro
especulativa
LRQ (32 entradas)
Problema
•  Un procesador aplica la técnica de store forwarding con las siguientes características
para las instrucciones de acceso a memoria:
–  Etapas: Load: IF, ID, I, AC, L1, L2, WB, C Store: IF, ID, I. AC, C, L1, L2
–  Issue load/stores: lanzamiento desde IQ y lectura registro de dirección base
–  AC: cálcula la dirección y la pone en la LQ o SQ sin hacer uso del bus común
desde donde se lanzará a memoria
–  L1 L2: acceso a memoria en 2 ciclos, segmentado
•  En el primer ciclo (L1) las loads acceden a la cache y a la SQ en paralelo, para buscar
dependencias con stores previas
•  Si hay dependencia, L1 se repite hasta que esté el dato, aunque ya no se busca en la
cache, solo en la SQ
•  Cuando las stores tienen el dato y la dirección ponen el bit completed a 1 en la SQ,
y es accesible por las lodas en el siguiente ciclo
•  Si se encuentra el dato en la SQ cuando se está accediendo en paralelo a la cache, la
load lee el dato y realiza WB al siguiente ciclo.
•  Para iniciar el acceso a la cache debe encontrarse libre tanto la cache como la SQ
–  WB: las loads escribe en el bus común
•  Operador de multiplicación: latencia 3 ciclos, M1, M2, M3.
•  Operadores enteros: latencia un ciclo, EX
•  Hay una IQ compartida para enteros y reales (solo una puede hacer issue)
©Julio Sahuquillo
Problema
•  Realizar el diagrama de instrucciones/ciclos para el siguiente
fragmento de código hasta la segunda load de la segunda iteración
del bucle
•  Indica en que ciclo se escribe/lee el dato en/desde la SQ
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18!
L:! IF ID
L.D F2,8(R2)! I AC L1 L2 WB C!
L.D F3,0(R2)! IF ID I AC L1 L2 WB C!
MUL.D F4,F3,F2! IF ID - - - I M1 M2 M3 WB C!
S.D F4,0(R2)! IF ID I AC - - - - cp - C L1 L2!
DSUB R2,R2,#8! IF ID I EX WB C!
BNEZ R2,L! IF ID - I EX WB C!
L.D F2,8(R2)! IF ID - I AC L1 SQ WB C !
L.D F3,0(R2)! IF ID - I AC - L1 L2 WB C!
!
!
!
!
©Julio Sahuquillo
Problema
•  Realiza de nuevo el diagrama asumiendo que el procesador es
superescalar de 2 vías con las siguientes características
–  Si la load detecta una dependencia con una store en la SQ la load se
relanza 3 ciclos después
–  La cache tiene 1 puerto de R/W
–  Puertos de issue: se pueden lanzar 2 de reales y 2 de enteros en el
mismo ciclo, o 2 loads y una de enteros.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15!
L:!
L.D F2,8(R2)! IF ID I AC L1 L2 WB C!
L.D F3,0(R2)! IF ID I AC -- L1 L2 WB C!
MUL.D F4,F3,F2! IF ID - - - - I M1 M2 M3 WB C!
S.D F4,0(R2)! IF ID I AC - - - - - - cp C L1 L2!
DSUB R2,R2,#8! IF ID I EX WB C!
BNEZ R2,L! IF ID - - I EX WB C!
L.D F2,8(R2)! IF ID - I AC L1 - - L1 SQ WB C !
L.D F3,0(R2)! IF ID - I AC - L1 L2 WB C!
!
!
©Julio Sahuquillo
!
!
Implementación eficiente del wakeup

•  El wakeup notifica que el dato se encuentra disponible.
–  Solución 1: asumido hasta ahora. El dato se encuentra disponible en el
banco.
–  Ejemplo procesador supersegmentado el issue en 3 ciclos, con 2 etapas
entre el wakeup y la ejecución:
–  Hay 3 ciclos entre las etapas de ejecución ! pérdida de prestaciones
significativa.
Lectura
Productor Wake-Up Select Registros Execution WriteBack akeu
p
l de w
Seña
Lectura
Wake-Up Select Registros Execution
Consumidor
3 ciclos de burbuja
Implementación eficiente del wakeup
•  Solución 2. Objetivo: que el dato se pueda consumir en el ciclo
posterior al que se produce.
–  Generar la señal antes de que el valor se produzca para minimizar la
distancia entre el productor y el consumido.
•  La señal se puede generar antes porque una instrucción no necesita el
dato hasta que llega a su etapa de ejecución.
•  Ejemplo:
–  Asumiendo latencia del operador de 1 ciclo, la señal se puede enviar en la
etapa que se selecciona el productor porque se sabe la latencia de lectura
(1 ciclo) y la del operador.
–  En este caso nos hace falta un cortocircuito desde la salida del operador
del productor al operador del consumidor.
Lectura
Productor Wake-Up Select Registros Execution WriteBack
Señal de wakeup Data Bypass
Lectura
Consumidor
Wakeup conservativo de loads

•  Wakeup conservativo: se envía la señal cuando se sabe que hay
acierto en la cache.
–  Ejemplo procesador supersegmentado, el acceso a memoria consta de
cálculo de dirección, detección de acierto o fallo, y acceso a la cache.
–  Hay 2 ciclos de burbuja desde que leemos el dato de la cache.
Lectura Cálculo Acierto/ L1 cache

Load Wake-Up Select Registros Dirección Fallo access
Wakeup
Lectura
Consumidor
2 ciclos de burbuja
Wakeup especulativo de loads
•  Wakeup especulativo:
–  Objetivo: que el consumidor pueda usar el dato (bypass) justo después de
la lectura en la cache.
–  Ejemplo procesador supersegmentado
•  La señal wakeup se debe enviar en la etapa del cálculo de la dirección, antes
de saber si hay acierto o no en la cache ! wakeup especulativo,
ya que si hay fallo de cache, la ejecución será incorrecta y deberá recuperarse
el estado del procesador.
Lectura Cálculo Acierto/ L1 cache

Load Wake-Up Select Registros Dirección Fallo access
Wakeup Data Bypass
Lectura
Consumidor
Wakeup especulativo de loads

•  Problemas:
–  Cuando una instrucción deja la cola de instrucciones no hay ninguna garantía de
que haya una entrada libre y para que pueda volver.
–  ¿solución?¿esperar a que se libere una? No, ! se pueden producir bloqueos si la
cola está llena de instrucciones dependientes que no liberan su entrada.
–  Soluciones:
•  Eliminar todas las instrucciones del pipeline más jóvenes que la load y reanudar
la ejecución ! pérdida de prestaciones importante si ocurre a menudo.
•  Liberar la entrada cuando se sabe que la load no debe relanzarse
! reduce el número de entradas “efectivas” de la Issue Queue
! pérdida de prestaciones
! la cola debe ser pequeña para respetar el tiempo de ciclo.
•  Implementar una “replay queue” (arquitecturas netburst de Intel)
cuando se lanza una instrucción deja la Issue queue y se encolan en orden
FIFO en la “replay queue” hasta que se garantiza que no deben relanzarse
! si necesitan relanzarse el planificador da prioridad a la replay queue y se
relanzan en el orden en que fueron almacenadas.
FIN
•  Esquemas de desambiguación
–  Orden total de loads y stores
•  Todas las instrucciones de acceso a memoria se ejecutan en orden
–  Orden de loads / Orden de stores
•  Ejecución o-o-o entre loads y stores pero
las loads y las stores se ejecutan en orden entre ellas
•  Ej. AMD K6
–  Orden Parcial
•  Las loads se ejecutan o-o-o entre ellas
si las direcciones de todas las stores previas son conocidas
•  Ej. R10000, AMD K8
–  Desambiguación especulativa
•  Las loads se ejecutan completamente o-o-o aunque la dirección de las stores
previas no sea conocida
•  Ej. Intel core y Alpha 21264
Implementación con 1 única cola
•  Load bypassing
LSQ
sw sw sw Operación
lw reg, M(100)‫‏‬
@
200 250 300
dato
4 4 2
•  Load forwarding
LSQ
sw sw sw Operación
lw reg, M(100)‫‏‬
200 @
100 300
dato
4 4 2
10. Caso de estudio: MIPS R10000

•  Tiene 3 colas de instrucciones. Cuando se decodifica una instrucción la pone en una
cola excepto NOPs y jumps
–  Cola de Enteros 16 entradas
•  La entrada se libera cuando se lanza a la ALU
–  Cola de Reales 16 entradas
•  Similar pero no contiene valores de operandos inmediatos
–  Cola de direcciones Address queue
•  Cuando se decodifica load/store
–  Rellena una entrada en la cola
•  Cola FIFO utilizada para mantener el orden
•  Lanza instrucciones a la unidad cálculo de dirección y a la Dcache
•  Más compleja que la de enteros: requiere soporte para relanzamiento
ROB
lw A add sub sw B …
dispatch
Address Queue
lw A sw B …
Caso de estudio: MIPS R10000

•  Cálculo de la dirección
–  2 etapas: cálculo de la dirección y
traducción en la TLB
–  El puerto de lanzamiento lee el
operando del BR de enteros
•  Loads:
–  Si Dcache accesible se accede al
mismo tiempo que la TLB cuando
se lanza
•  Ejecución loads
–  Ejecución en cualquier orden si no hay dependencias con stores previas
pendientes
•  Ejecución stores
–  Stores: orden estricto
•  La memoria se actualiza en orden - 1store/ciclo
•  Mantiene valores de memoria precisos ante cualquier excepción
ROB
… lw A add sub sw B
Buffer de stores head
… … sw B
head

Tema 3. Arquitectura Del Core - Planificacion de Instrucciones - Soluciones PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 3. Arquitectura Del Core - Planificacion de Instrucciones - Soluciones PDF

Cargado por

Copyright:

Formatos disponibles

TEMA 3.

Arquitectura del core:

©Julio Sahuquillo -2-

• Implementación de la ventana de instrucciones

• Según la implementación variará

©Julio Sahuquillo -3-

1. Introducción: lógica de lanzamiento

Destino Operando 1 Operando 2

©Julio Sahuquillo -4-

Destino Operando 1 Operando 2

©Julio Sahuquillo -5-

Ventana distribuida: número de entradas

• Planificación de loads y stores en orden.

©Julio Sahuquillo -6-

Efecto del nº de entradas en cada ER (por operador)

©Julio Sahuquillo -7-

Ventana distribuida: impacto lógica simple

2 inst. decoder 4 inst. decoder

Lanzamiento FCFS versus out-of-order

©Julio Sahuquillo -9-

©Julio Sahuquillo -10-

• Las instrucciones no lanzadas se quedan en la pila en orden de

©Julio Sahuquillo -11-

ANTES DE LANZAR DESPUÉS DE LANZAR

Pila de dispatch Pila de dispatch

©Julio Sahuquillo -12-

Efecto del tamaño de la pila de dispatch

©Julio Sahuquillo -13-

Pila de dispatch vs ventana distribuida

• ROB + cola de instrucciones (ventana central)

©Julio Sahuquillo -15-

ROB + ventana central

ANTES DE LANZAR DESPUÉS DE LANZAR

Cola de issue Cola de issue (ventana central)

• Prestaciones con lanzamiento basándose en la posición de la ventana

©Julio Sahuquillo -17-

4. Complejidad etapa de issue

©Julio Sahuquillo -18-

©Julio Sahuquillo -19-

4. Complejidad etapa de issue

T wakeup T selección T lanzamiento

©Julio Sahuquillo -20-

©Julio Sahuquillo -22-

¿Qué pasaría si la segunda o la primera load fallasen en L1?

• Existen largas cadenas de instrucciones dependientes de las loads

Cálculo de dirección y acceso a memoria

• Fases en la ejecución de una instrucciones de acceso a memoria:

• Muchos procesadores dividen la instrucción internamente en 2:

• Los pasos 2 y 3 se suelen realizar en paralelo

• Desambiguar: averiguar si hay dependencias o alias

• Orden total de loads y stores

– Suficiente pero no necesaria

Ejemplo limitación prestaciones

Bucle: ld F2, 0(Rx)

• No existen dependencias de datos entre iteraciones distintas

– Las loads se encuentran en el camino crítico

8. Load bypassing y load forwarding

• Esquemas de adelantamiento de loads

Cola de loads y cola de stores

Load bypassing con SQ

Load forwarding desde la SQ

Realiza el ejercicio anterior con bypassing

– Con bypassing (asumiendo que las loads no dependen de

•  Implementación de la ventana de instrucciones

•  Según la implementación variará

•  Planificación de loads y stores en orden.

•  Las instrucciones no lanzadas se quedan en la pila en orden de

•  ROB + cola de instrucciones (ventana central)

•  Prestaciones con lanzamiento basándose en la posición de la ventana

•  Existen largas cadenas de instrucciones dependientes de las loads

•  Fases en la ejecución de una instrucciones de acceso a memoria:

•  Muchos procesadores dividen la instrucción internamente en 2:

•  Los pasos 2 y 3 se suelen realizar en paralelo

•  Desambiguar: averiguar si hay dependencias o alias

•  Orden total de loads y stores

–  Suficiente pero no necesaria

•  No existen dependencias de datos entre iteraciones distintas

–  Las loads se encuentran en el camino crítico

•  Esquemas de adelantamiento de loads

–  Con bypassing (asumiendo que las loads no dependen de

•  Ejemplo de fallo de especulación

•  Loads: almacenan su dirección en la load queue.

–  ESQUEMA 1: cambio simple

–  ESQUEMA 2: Tabla de predicción de load: utilizado en la arquitectura Intel Core

•  La LQ tiene 4 campos: etiqueta, dirección, spec y update

•  Se utiliza una tabla auxiliar con contadores con saturación,

–  ESQUEMA 2: Tabla de predicción de load: (cont)

•  Cuando la store llega a la etapa etapa de commit

•  Cuando una load llega a etapa de commit (no ha sido abortada)