Dans MIPS, une instruction I-Type peut-elle provoquer un danger?

Question

Je sais que les instructions R-type consécutifs peuvent causer un danger, par exemple:

add $2, $2, $1 
add $2, $2, $3 

mais peut instructions de type I consécutifs? Par exemple:

addi $2, $0, 10 
addi $2, $0, 5 

Answer 1

compte tenu de votre cas:

addi $2, $0, 10 
addi $2, $0, 5 

vous ne rencontrerez jamais un danger de données parce que vous ne lisez une valeur après est en cours d'écriture (lecture après écriture)

peut-être penser comme ça:

$2 = $0 + 10 
$2 = $0 + 5 

vous pouvez voir que $ 2 n'est pas utilisé dans le s Le calcul econd et $ 0 ne sont pas modifiés, donc il n'y a pas de danger pour les données.

si vous deviez le faire:

addi $2, $0, 10 # $2 = $0 + 10 
addi $3, $2, 5 # $3 = $2 + 5 

pipelining ne garantit pas que 2 $ est la valeur attendue quand il est lu au cours du deuxième calcul. Considérons que lw et sw sont également des instructions de type I;

RAW 
    A Read After Write hazard occurs when, in the code as written, one instruction 
    reads a location after an earlier instruction writes new data to it, but in the 
    pipeline the write occurs after the read (so the instruction doing the read gets stale data). 
WAR 
    A Write After Read hazard is the reverse of a RAW: in the code a write occurs after a read, 
    but the pipeline causes write to happen first. 
WAW 
    A Write After Write hazard is a situation in which two writes occur out of order. We normally 
    only consider it a WAW hazard when there is no read in between; if there is, then we have a RAW 
    and/or WAR hazard to resolve, and by the time we've gotten that straightened out the WAW has 
    likely taken care of itself. 

http://www.cs.nmsu.edu/~pfeiffer/classes/473/notes/hazards.html

étant donné que les opérations pour les données de lecture et d'écriture sont des instructions de type I et compte tenu de la définition de ces dangers potentiels de données, oui, des instructions de type I peuvent encore avoir un danger.