CRITICITA' SUI  DATI

RAW hazards.

1. Windlx li riporta nelle statistiche quando il forwarding è disabilitato.

E' il classico tipo di RAW hazard, può accadere innumerevoli volte e non si può lasciare al compilatore la risoluzione di tutti questi casi (il compilatore inserirebbe, quando possibile, un'altra istruzione fra le due add) .

Per risolvere questo hazard basta abilitare il forwarding:

Forwarding disabilitato

add      r1, r2, r3 add      r4, r1, r2

Forwarding abilitato

2.  LD Stalls

Lo stallo è causato dall'istruzione load.

lw      r1, 4(r3) sw     0(r1), r2

3. Branch/Jump instruction.

Questo caso è simile al punto 1, però non può essere risolto allo stesso modo. Infatti l'istruzione beqz richiede di conoscere il valore di r1 nello stadio ID (decodifica delle istruzioni e lettura da register file).

add       r1, r2, r3 beqz     r1, Finish

4. Floating point instruction.

Caso a.

Un'istruzione dipende dal risultato di un'istruzione precedente che, a causa del ritardo dovuto all'unità di elaborazione floating-point, non ha ancora finito lo stadio che coinvolge la ALU. In questo caso gli stalli dipendono essenzialmente dal tipo di operazione che deve essere svolta (ovvero dalla durata dell'operazione) e quindi possono propagarsi anche per molte istruzioni successive.

Windlx assume come default i seguenti valori:
Addition unit    2
Multiplication unit   5
Division unit    19

Esempio di una mult (l'hazard si propaga per 5 cicli):

multu      r5, r11, r12  addi       r1, r1, 1 add        r1, r2, r2 add        r1, r2, r5

Caso b.

L'istruzione fp si trova a passare allo stadio MEM nello stesso ciclo di clock di un'istruzione intera, in questo caso (almeno per ciò che riguarda WinDlx), l'istruzione fp ha la precedenza. (ricordo che addf richiede due cicli per la ALU)

addf      f5, f11, f12  add       r1, r2, r2

Caso c.

In questo caso la situazione è un po' più strana in quanto quello della terza istruzione non è uno stallo vero e proprio. Lo stallo si propaga dalla prima istruzione: quando la terza dovrebbe entrare nello stadio della ALU lo trova già occupato dalla seconda. Ma quello che voglio far notare è che se la terza istruzione usasse l'unità floating-point potrebbe andare avanti regolarmente!   

addf          f5, f11, f12  movi2fp   f1, r1 cvti2d      f10, f10

WAW  hazards.

Questo tipo di stalli possono avvenire soltanto in pipelines che possono scrivere  (WB stage) in più di uno stadio: nel caso di WinDlx ciò non è possibile.

Si possono comunque verificare con istruzioni floating-point, ad esempio:

multf      f5, f11, f12 addf       f5, f1, f1

Vengono inseriti ben 4 stalli, ma se ciò non avvenisse la multf scriverebbe in f5 un valore incoerente con quello che ci si aspetterebbe dal normale flusso del programma.