Are WAR and WAW hazards only possible if we have parallel computing

Question

I was reading on WAW and WAR data hazards and I think that these can only happen if we have parallel computing ,in contrast with RAW data hazard which can happen even if we dont have parallel computing.Isn't this true,right?

Answer 1

To answer the question, you have to check what point of view is to apply and what could happen if we don't obey the dependency solving (so this is why it's called "hazard").

Consider the Wikipedia example for WAW hazard:

i1. R5 <- R4 + R7
i2. R5 <- R1 + R3

Imagine the same logical processor executes this. We don't ask now why this order of operations appeared when R5 value after i1 is not used. There may be, for example, condition code setting in an architecture where we can't disable this setting (as in x86), so, where R5 is written above we assume CF, ZF, SF... There may be another side effect of an instruction, like putting remainder to a register when only quotient is needed but the instruction always writes both. Whatever. But, if you don't respect the instruction order and, after retiring both i1 and i2, R5 will contain result of i1 and not of i2 - your ordering failed.

So, the implementer has to take this case into account. Whatever reason was in effect when the code was written, obey the ordering rules and show the final result.

You are right that concurrent execution on different logical processors (AKA harts AKA more terms are known) may also expose the hazard. But this is less typical. Most cases of concurrent modification of a location implies read-modify-write manner with fetched value checking, even if it just a counter increment. But plain write to a shared location may be used in some specific scenarios: for example, the last modification source is written for diagnostic purposes.

For WAR hazard, the situation is simpler. (Notice that typically hazards are defined within a single pipeline.) Again, the Wikipedia example:

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

What happen if i2 changes R5 before execution of i1? Certainly, nothing good. Either i2 store phase shall be ordered after i1 fetch phase, or register renaming shall separate them into different physical registers. And this is effective within a single logical processor, no need to enlist multiple ones.

I should notice the wording there is slightly confusing. The phrase like "represents a problem with concurrent execution" is an ambiguous hint, unless the reader constantly bears in mind that the whole description pertains to a single pipeline, not different concurrent ones. Concurrent execution here is of neighbor instructions.