 For this example, we're going to be working with this set of code. We're going to see how it's going through our algorithm, where it's going, and at which cycles. In this case, we have a processor with two ALU units and a load store unit. We've got our common instruction fetched to code hardware, as well as a commit unit. We're going to be able to issue two instructions every cycle, and we'll commit two instructions back every cycle. So, for example, in our first cycle, both of our load words come in. Get both of those in cycle one. Cycle two, both of those are going to go off to the memory unit. But since a functional unit can only process one of these two instructions every cycle, it's just going to process one of them in cycle three. Then it will be free in cycle four, and it can process the other one. Once the first load word has been computed, then it will go off to the commit unit. It'll arrive there in the same cycle that it was processed. But it may have to wait there for a while. Same thing with our second load off to the commit unit after being processed. Now, we can commit this instruction immediately, as well as the other one. As soon as those have arrived, they can be committed in the next cycle. Now, there was actually a dependency between these two instructions, but this instruction was delayed because the functional unit was in use. It was also going to be delayed because it didn't have one of its two parameters. It needed to get zero from the first load word instruction. The second cycle will get in the third load word and the intermediate instruction. Then in the third cycle, we'll get in two more instructions. Then in the fourth cycle, we'll get the last one instruction to come in. We're always just going to issue two instructions every cycle. We're going to assume that our reservation stations have sufficient space for the handful of instructions that we've actually got. And we'll just worry about issuing them to the various functional units and when they get committed now. Our third load word depends on the results of our second load word instruction as well. It will go off to the memory unit in cycle three, but it does need to wait until the second load word has computed. It also has to wait for the memory unit to be available, so there's no way that this instruction will be computed before cycle five. It can then go off to the commit unit and it can be committed in the next cycle. Our intermediate instruction is dependent on T2, so it needs the results of the third load word. I'll send it off to the first ALU. That seems reasonable and it would get there in cycle three, but we need to wait until this piece of data is available. It will be found in cycle five, so it will be available to use in cycle six. After that, it will then go over to the commit unit and it can be committed in the next available cycle. Now I have a store word and an intermediate instruction. The store word is dependent on both T1 and T2, so we have to be sure that both load word number one is completed and our intermediate have completed. So this is a store word instruction. It will go off to memory right there in cycle four, but it needs to wait until its data is available. The data will be computed in cycle six, so it would be available to run in cycle seven when our memory unit is not in use. And that will end up at the commit unit in cycle seven, and we can commit that back in cycle eight. For our intermediate instruction, it's just dependent on S0. We don't have an S0 in here, so we're going to be able to run this instruction immediately. I can pass it to either one of my ALUs. At the moment, ALU two is empty, so I'll send it there. I'll arrive there in cycle four, and since it doesn't have any dependencies, it can run immediately. It can run in cycle five. Then it would end up at the commit unit in cycle five. But I need to be sure that I commit all of my instructions in order, so I can't actually commit my intermediate instruction in cycle six, even though there's actually an opening there, we could commit two instructions in cycle six. I really need to wait until all of the previous instructions have been committed. So since there's a second opening in cycle eight, I will be able to commit my intermediate in cycle eight as well. Lastly, I have my add instruction. It's dependent on T4 and S5, neither of which have been updated. So I'm going to be able to run that immediately. In this case, I could send it to either of my ALUs. If I send it to ALU one, then it would arrive here in cycle five. It wouldn't be able to run in cycle six, so I would have to run it in cycle seven. Alternatively, if I send it to ALU two, it will arrive there in cycle five. And then this ALU will be free in cycle six, so I can run our add instruction immediately, send it over to the commit unit, and it will sit there until all of the other instructions have been completed first. In this case, the instructions will... In this case, the previous instruction isn't going to be committed until cycle eight, and we've already got two instructions being committed that cycle, so our add instruction won't be able to be committed until cycle nine. So that is how this list of instructions would be processed through our processor. Most of our instructions are going off to the memory. A handful of them are being sent to each of the ALUs. We had some option about which of the individual ALUs we sent these instructions to, and then the only other thing we needed to do was make sure that we committed all of our instructions in order. We issued all of them in order, and we commit them all back in order.