 This time we're going to be looking at the second type of hazard, data hazards. Data hazards occur when two instructions try to access the same piece of data, either in a register or in a block of memory. We'll be looking at three different types of data hazards, read after write, write after read, and write after write. For the MIPS architecture, we're only going to be interested in one of these at the moment, the raw hazards, but we'll see how all three of them work and how they can occur. So a write after write hazard occurs when one instruction tries to read something that the previous instruction had just written. In our single-cycle architecture, we didn't have any problems there, because one instruction had to complete before a second one could start. In our multi-cycle pipeline, one instruction could start and try to read from a register before the previous one had written its results to a register or to memory. So this type of hazard occurs when we have two instructions nearby, such as these, where one instruction is going to write to a register, and the next instruction is going to read from that register. So here you can see we've got T0 in both of these, and our second instruction wants to use T0, but our first instruction is going to update it. So if our second instruction gets to read from T0 before the first one has had a chance to write to it, then the second instruction is going to get some old data. This is the one type of hazard that we can have with the MIPS architecture, so we will need to find ways around this, but it's relatively straightforward and easy to see. Our second type of hazard is a write after read hazard. This type of hazard occurs when one instruction tries to write to a register before the previous one has done reading from it. This can happen when one instruction is capable of writing to a register very early in its pipeline, before the previous one has had a chance to actually read from it. This requires some odd structured instructions, but if you have some instructions that take a really long time, then this type of problem can start to arise. Our third type of hazard is a write after write hazard. This type of hazard occurs when one instruction tries to write to a register after the previous one did. Similar to the write after read hazard, this kind of hazard can occur when one instruction is capable of writing to a register really early in its pipeline before the other one has had a chance to. So in this case, the second instruction might complete. It writes its results to T0 and the first one is still doing its computation. If that occurred, then the first one would eventually finish and it would overwrite the results of the second to add instruction, leaving us with the results of the first instruction instead of the ones that we actually want. The fourth type of hazard you could envision would be a read after read hazard, but those don't really exist because reading doesn't change the state of our system, so it doesn't really matter what order you do your reads in. What does matter is when you start having writes involved as well. Fortunately for our MIPS architecture, we only have to worry about raw hazards. We won't have to worry about war or write after write hazards. But we will see how these can affect things later on when we start looking at even more complicated architectures.