CONFLICTOS EN EL PROCESAMIENTO SEGMENTADO

En los procesadores segmentados, a los problemas potenciales que

pueden ocurrir se les conocen como Hazards.
Las instrucciones de un procesador segmentado son ejecutadas en varias
etapas, de modo que en un momento dado se encuentran en proceso
varias instrucciones y puede que éstas no sean completadas en el orden
deseado.
Un riesgo aparece cuando dos o más de estas instrucciones simultáneas
(posiblemente fuera de orden) entran en conflicto.
Existen 3 clases de conflicto:
 Conflictos estructurales.
 Conflictos por dependencia de datos
 Conflictos de control.

1. Conflictos estructurales: También llamados Structural Hazard, estos

son causados por insuficiencia del hardware, ya que esta siendo usado y
por lo tanto provoca que una etapa no pueda avanzar.
Este tipo de conflicto puede resolverse, en causes monofuncion (puede
realizar una función fija), duplicando los recursos del hardware que sea
necesario (no recomendable) o duplicando archivos de registro que
también nos lleva a problemas de inconsistencia.

Uno de los SH más

frecuentes son los de
acceso a memoria los
cuales ocurren en el
momento de leer una
instrucción y acceso de
un dato. Este conflicto se
resuelve mediante la
arquitectura Harvard en
la cual existen memorias
cache para instrucciones
y datos.

Pero aun así hay conflictos cuando existen accesos simultáneos de datos
por parte de varios segmentos. Para esto se agregan nuevos puertos a la
cache de datos o también limitando los accesos a datos a determinadas
 instrucciones para que sea difícil que se superponga(arquitecturas
registro-registro o carga-almacenamiento).
El problema todavía se agrava más en los cauces multifunción
dinámicamente configurables. En estos casos ocurren las colisiones que
son usos simultáneos de varios segmentos por parte de ejecuciones
distintas de una misma función o por varias funciones. Para este
problema se lleva a cabo las llamadas tablas de reservas, las cuales
contienen información sobre la ocupación de cada segmento en cada uno
de los ciclos máquina. Las filas representan a los segmentos y las
columnas a los ciclos necesarios para la ejecución de la tarea.

¿Qué hay que hacer para resolver esto? Pues la respuesta es algo simple
en realidad, lo que se tiene que hacer es superponer la misma tabla, pero
desplazada un espacio a la derecha y si hay un espacio de segmento que
esta siendo ocupada por la tabla original y desplazada es imposible que
se ejecute por segunda vez esa instrucción en el siguiente ciclo del
procesador. Se seguirá desplazando hasta que las dos tablas no ocupen
un mismo segmento.

El numero de desplazamiento entre ambas tablas nos indica el número de

ciclos que hay que esperar(Latencia).

2. Conflictos por dependencia de datos: este conflicto se da cuando una

instrucción necesita los resultados de otra anterior, que aun no ha
acabado de ejecutarse y no tiene listo los resultados. Si estas
dependencias no son resultas no son resueltas provocaran riesgos de
datos o incluso condiciones de carrera.

Existen 3 tipos principales de dependencias:

 RAW - READ AFTER WRITE (LECTURA DESPUÉS DE ESCRITURA)

 La instrucción B trata de leer un operando antes de que la instrucción A lo
haya escrito; de esta forma, B puede tomar un valor incorrecto de ese
operando. Este es el tipo de dependencia más común.

Una dependencia RAW hace referencia a una situación donde se necesita

un dato que aún no ha sido calculado, por ejemplo:

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

La primera instrucción calcula un valor que será guardado en el registro

R2, mientras que la segunda necesita este valor para computarlo y
almacenar el resultado en el registro R4. Sin embargo, en un procesador
segmentado, cuando se capturan los operandos para realizar la segunda
instrucción, los resultados de la primera aún no han sido guardados, de
forma que aparece una dependencia de datos.

La existencia de riesgo o no depende de la separación de temporal de las

instrucciones A y B, así como de la profundidad de la segmentación.

 WAR - WRITE AFTER READ (ESCRITURA DESPUÉS DE LECTURA)

La instrucción B trata de escribir en un registro antes de que sea leído por

la A; por ello, A tomaría un valor incorrecto, ya que debería tomar el valor
antes de modificarse. Este riesgo es poco frecuente, debido a que la
escritura de los resultados se efectúa en los últimos segmentos y es difícil
que esa escritura se adelante al segmento de lectura de una instrucción
anterior.

Una dependencia WAR representa un problema de ejecución

concurrente, por ejemplo:

i1. r1 <- r2 + r3
i2. r3 <- r4 x r5

Si por alguna razón la instrucción 2 puede finalizar antes de que lo haga

la 1 (por ejemplo, en ejecución concurrente), es necesario asegurarse de
que no se almacenará el resultado en el registro R3 antes de que la
instrucción 1 haya podido leer sus operandos.
 WAW - WRITE AFTER WRITE
La instrucción B intenta escribir un operando antes de que sea escrito por
la A. Dado que las escrituras se están realizando en orden incorrecto, el
resultado final depositado es el correspondiente a la instrucción A cuando
debería ser el depositado por la B. Este conflicto solo se produce en
procesadores segmentos que escriben en más de una etapa y esto no es
muy frecuente.

Una dependencia WAW es otra de las posibles situaciones problemáticas

en un entorno de ejecución concurrente, por ejemplo:
i1. r2 <- r1 + r3
i2. r2 <- r4 x r7
En este caso debe retrasarse la escritura (etapa WB) de la instrucción 2
hasta que la instrucción 1 haya finalizado.

3. Conflictos de control:
Estas se deben a las instrucciones de control de flujo, en que no se puede
leer la instrucción siguiente hasta que se conozca su dirección.
¿Pero por qué ocurre este problema?
_ El cálculo de la dirección de destino se efectúa en la fase de escritura
de resultado y esta fase suele ser en la mayoría de casos la última. Por lo
que una instrucción de control de flujo provocara una detención del
procesador.
Otros conflictos de este tipo que podríamos mencionar, aunque un poco
más difíciles de controlar, serían las interrupciones, dado que estos casos
no están previstos dentro de la ejecución de un programa.
Podemos mejorar este tiempo si dejamos que se continúen leyendo
instrucciones. De esta manera si la condición de salto no se da ya se
habrá avanzado algo.
Una de las soluciones para evitar esta perdida de rendimiento es hacer
que el compilador encuentre algo que hacer mientras se calcula la
dirección de destino de salto. Si el compilador no pudiera encontrar
ninguna instrucción para ocupar los huecos libres dejados por las
instrucciones de salto, rellenaría con instrucciones NOP.