 This time, we're going to go into a little more depth on Thomas Sulu's algorithm and look at how it performs register renaming. Thomas Sulu's algorithm allows us to get around lots of read after write, write after write, or write after read hazards kind of automatically. We don't even have to worry about them. Before we saw that we could get rid of read after write hazards, just by waiting for all of our instruction parameters before executing. So whenever one of my parameters isn't available immediately, I just write down where I'm going to get that from and then wait for it. I don't just go grab that from a register and then get annoyed when some other instruction updates the register that I just pulled data out of. I just wait for that data to be available. Just wait for it to be computed. But we're going to eliminate right after hazards using register renaming instead. So instead of just referring to the regular block of registers that we've got, say T0 through T9, we could rename or replace a register to avoid a hazard. Can imagine, say this block of code got here has lots of dependencies in it, lots of potential hazards. I've got a couple of read after write hazards, say between my add instruction and my multiply instruction or my store word to my add instruction. Both of those cases would just be handled by waiting for our data to be available. We've also got some write after hazards. For example, we've got a write after write hazard between our add instruction and our multiply instruction. Our add instruction wants to update T0, so does our multiply instruction. We need to make sure those happen in order. We also have another write after write hazard between our two add instructions, since both of them want to update T0. We also have a couple of write after read hazards. One between the add and the multiply instruction and another between the add and the store word. In this case, we're going to try to update the value of T0. We need to make sure we've read that data out of T0 before we update that register. So if we apply some register renaming to this, we're just going to change the name of a bunch of those T0s. Now you can really easily see at the end of this block, only thing that's updated T0 is that last add instruction. It was completely independent of everything else, but it had a whole bunch of potential hazards there. Now we've got two new registers that we've named A and B. They clearly don't correspond to any of the registers we're used to. But we can tell that they're distinct. We can see where our dependency is on the A register. We can also see where the dependency is for B. We can also see that we don't have any more conflicts there. We've avoided most of the conflicts and now we're just left with the potential read after write hazards. And we already know how to handle those. So Tomasuno's algorithm performs register renaming automatically for us just by referring to which instruction is going to compute data for us. So essentially we have a huge pile of extra registers in our hardware. One corresponding to each of the reservation stations that we've got. Our reservation stations will have seven different fields that we'll be looking at they'll have the operation that you actually want to do that goes in the drop field. If you have the data available to you, it will go into VJ and VK. But if that data isn't available yet, then you'll write down where you're going to get that data from in either QJ or QK, depending on which piece you need. The A field is primarily used for address computation. The busy field just serves to tell us which instruction we're actually running this cycle. So next we'll look at how all of these get processed in such a way that our architecture just happily processes lots of instructions concurrently.