La tubería no tiene que vaciar para la instrucción de bucle si la CPU puede deducir que la rama es incondicional y obtener las instrucciones del objetivo de la rama en lugar de la siguiente instrucción. (Para las ramas condicionales, esto también es posible gracias a la predicción de la rama).
Sin embargo, está la pregunta: en qué etapa de la tubería se encuentra la instrucción como un salto incondicional.
Estoy de acuerdo con Dave Tweed en que existe un peligro de lectura y escritura debido a la actualización del mismo registro. Sin embargo, puede que en realidad no lleve a un bloqueo en la tubería, ya que puede resolverse con un bypass.
Supongamos que su tarea se basa en el "pipeline RISC clásico de cinco etapas" .
Supongamos que solo tenemos instrucciones INC R1 sucesivas. Una forma de lidiar con el peligro sería imponer un puesto de tres ciclos:
t0 t1 t2 t3 t4 t5 t6 t7
INC R1 [IF] [ID] [EX] [ME] [WB]
INC R1 [IF] .... .... .... [ID] [EX] [ME] [WB]
El operando se recupera en la etapa de ID, por lo que la segunda ID del INC tiene que esperar hasta que se complete el primer WB del INC. Pero esto se puede mejorar considerablemente con un bypass, que puede reenviar el valor de R1 sin tener que esperar a la etapa WB:
t0 t1 t2 t3 t4 t5 t6 t7
INC R1 [IF] [ID] [EX] [ME] [WB]
\ bypass
INC R1 [IF] [ID] .... [EX] [ME] [WB]
Se permite que la etapa de ID obtenga los datos incorrectos, pero la omisión lo corrige. Ahora el compilador o el programador de lenguaje ensamblador tiene que encontrar solo una instrucción para poner entre estos dos para eliminar el bloqueo, lo que es más fácil.
Como en el ejemplo de bucle inifinito, tenemos una instrucción, el peligro R1 se vuelve más o menos discutible, y el problema gira en torno a cómo se maneja la rama.
Digamos que la rama incondicional se reconoce por lo que es en la etapa de ID. Así que esto significa que la búsqueda continúa más allá de la rama. Vamos a denotar la siguiente instrucción como el pseudo-opcode ??? ya que no sabemos lo que es.
t0 t1 t2 t3 t4 t5 t6 t7
L: INC R1 [IF] [ID] [EX] [ME] [WB]
JMP L [IF] [ID] [EX] [ME] [WB]
??? [IF] ---- ---- ---- <-- scrapped; not happening
L: INC R1 [IF] [ID] [EX] [ME] [WB] <-- fetch continues at target
En t2, el JMP está en la etapa de decodificación, y ??? comienza a buscar El procesador se da cuenta de que ha descodificado un salto incondicional, por lo que tiene que volver a buscarlo desde el objetivo de la rama. Esto no significa que se vacíe una tubería, sino que se produce un retraso de un ciclo.
En algunos de los primeros procesadores MIPS, la instrucción que sigue a una rama no se desechó; sería ejecutado de todos modos. Depende del compilador (o programador de lenguaje ensamblador) hacer uso de esta ranura de retardo de bifurcación. Si el compilador no pudo hacer uso de la ranura de retardo de bifurcación, tiene que poner una instrucción NOP. Es probable que este problema no le importe a su pregunta de tarea: puede asumir que el ciclo es seguido por una instrucción inofensiva como NOP.
Pero en cualquier caso, la solución depende de los detalles del modelo de procesador con el que está trabajando y sus estrategias para enfrentar diversas situaciones en la tubería. Estudie y comprenda las reglas, y dibuje diagramas de "escaleras" para rastrear la evolución en el tiempo.