¿Cómo se ejecutan las instrucciones en una arquitectura segmentada?

Vi esta solución HW en el sitio web del curso CMU Comp Arch . Estoy leyendo ComputerArchitecture por mi cuenta. Solo tengo una duda.

Aquí está la pregunta HW:

Dado el siguiente código ( MIPS ):

MUL R3, R1, R2
ADD R5, R4, R3
ADD R6, R4, R1
MUL R7, R8, R9
ADD R4, R3, R7
MUL R10, R5, R6
Fetch (one clock cycle)
Decode (one clock cycle)
Execute (MUL takes 6, ADD takes 4 clock cycles). The multiplier and the adder are not pipelined.
Write-back (one clock cycle)

Calcule la cantidad de ciclos que se necesitan para ejecutar el código dado en una máquina segmentada con marcador y cinco sumadores y cinco multiplicadores sin reenvío de datos.

Aquí está la solución real:ingrese la descripción de la imagen aquí

Mi duda:

  • ¿Por qué la segunda instrucción ADD R5, R4, R3 está en estado de decodificación dos veces? (en 3er ciclo y nuevamente en 10mo ciclo)

  • ¿Por qué la tercera instrucción ADD R6, R4, R1 no hizo su 4to ciclo de estado DECODE?

Sigue los datos.
@ChrisStratton Estoy de acuerdo con la dependencia de datos. La segunda instrucción necesita R3 pero la primera instrucción no ha producido R3. Pero, ¿cómo responde eso a por qué DECODE debe ocurrir dos veces?
Eso depende de las reglas del lenguaje ensamblador no especificado citado. Si el primer registro dado es el destino, entonces la primera instrucción establece R3. ARM sería un ejemplo escrito en ese orden con registros nombrados como se muestra.
@ChrisStratton Después de que la primera instrucción produzca R3, el DECODE debe ocurrir solo en el décimo ciclo. Y debe ser NOP en el segundo ciclo, ¿verdad?
Presumiblemente, DECODE es donde descubre lo que necesita. Podría ser conceptualmente más claro si DECODE siguiera ejecutándose pero fallando en todos esos ciclos bloqueados hasta que finalmente tuviera éxito, pero puede que no sea así como realmente funciona o al menos no como su profesor quiere que piense al respecto.
@ChrisStratton Bien, ¿qué pasa con esto? ¿Por qué la tercera instrucción no está en la etapa DECODE en el cuarto ciclo?
Probablemente alguna regla sobre estar en un estado bloqueado se está filtrando. Mirándolo de otra manera, porque la segunda instrucción aún no ha salido de DECODE.
@ChrisStratton NO estoy asociado de ninguna manera con CMU. Ni siquiera soy un estudiante. Solo aprendiendo por mi cuenta.
@ChrisStratton Supongo que tu comentario suena lógico. El segundo no ha completado su DESCODIFICACIÓN hasta que R3 esté disponible. Entonces, la decodificación para la tercera instrucción ocurre en el ciclo 11 después de que finaliza la DECODIFICACIÓN de la segunda instrucción.

Respuestas (1)

¿Por qué la segunda instrucción ADD R5, R4, R3 está en estado de decodificación dos veces? (en 3er ciclo y nuevamente en 10mo ciclo)

La etapa de decodificación incluye la lectura de los operandos del archivo de registro. En el segundo ciclo, el decodificador descubre que uno de los operandos de la segunda instrucción aún no está disponible: la decodificación de la primera instrucción había marcado R3 como "ocupado". Por lo tanto, la decodificación de la segunda instrucción debe repetirse después de que la escritura de la primera instrucción haga que R3 "no esté ocupado". La escritura ocurre en el ciclo 9, lo que significa que la lectura puede ocurrir en el ciclo 10.

¿Por qué la tercera instrucción ADD R6, R4, R1 no hizo su 4to ciclo de estado DECODE?

Porque no se había completado la decodificación de la segunda instrucción. Las instrucciones deben decodificarse en secuencia, porque así es como se establecen las dependencias de datos.