1 00:00:03,033 --> 00:00:09,010 Let's move on to our second scheme. So our second scheme if you go back to 2 00:00:09,010 --> 00:00:13,560 the, the earlier slide. We said that you can either store pointers 3 00:00:13,560 --> 00:00:18,085 in the instruction queue and have pointers in the reorder buffer. 4 00:00:18,085 --> 00:00:23,064 Or we can just store the values. And if you go read the original 5 00:00:23,064 --> 00:00:26,328 reservation station paper by Thomas [inaudible]. 6 00:00:26,328 --> 00:00:33,067 He actually stored the values in the reservation station, or what we're calling 7 00:00:33,067 --> 00:00:36,631 the instruction queue and the reorder buffer. 8 00:00:36,631 --> 00:00:41,667 Okay, so a couple, a couple things change when you do this. 9 00:00:41,667 --> 00:00:46,868 One structure is missing. First of all, there is no physical 10 00:00:46,868 --> 00:00:49,089 register file. We removed that. 11 00:00:49,089 --> 00:00:53,696 We're going to store in flight instructions in a merged reorder buffer 12 00:00:53,696 --> 00:01:00,525 physical register file effectively. The second thing that's changed here is we 13 00:01:00,525 --> 00:01:04,710 no longer have a free list. And we'll see in a minute why we don't 14 00:01:04,710 --> 00:01:08,363 need the free list. But instead we're basically just going to 15 00:01:08,532 --> 00:01:13,320 use different reorder buffer and entries to keep track of our free list. 16 00:01:13,568 --> 00:01:18,437 And we're going to have to modobot, modify a bunch of stuff here. 17 00:01:18,437 --> 00:01:24,825 We're going to actually keep values in a reorder buffer instead of a pointer. 18 00:01:24,825 --> 00:01:31,817 Our renaming tables can be modified, our instruction ques now going to be able to 19 00:01:31,817 --> 00:01:38,355 keep track of actual data values. And our physical register file as I said 20 00:01:38,355 --> 00:01:42,004 before has gotten merged into our reorder buffer. 21 00:01:42,004 --> 00:01:51,328 For completeness here let's take a look at the where things get red and green in the 22 00:01:51,328 --> 00:01:57,708 pipeline and one, one notable change I wanted to say here is the architecture 23 00:01:57,708 --> 00:02:02,397 register file. Which in previous architectures was only 24 00:02:02,397 --> 00:02:06,504 written. We didn't do reading of it, except on 25 00:02:06,504 --> 00:02:10,156 rollback. We now, actually read from it, because we 26 00:02:10,156 --> 00:02:15,992 might need to be able to go find some canonical state in this architecture. 27 00:02:15,992 --> 00:02:26,362 So we, we add a R there to denote that. Okay, so let's look at how we have to 28 00:02:26,362 --> 00:02:31,231 modify the reorder buffer. Still looks like our reorder buffer from 29 00:02:31,231 --> 00:02:39,446 before. We need to know for the same reason in 30 00:02:39,446 --> 00:02:43,159 the, pointer-based design. We still need to know the architectural 31 00:02:43,159 --> 00:02:45,767 register number for the particular instruction. 32 00:02:45,767 --> 00:02:49,666 So this is when we go to write to the architectural register file. 33 00:02:49,666 --> 00:02:53,733 Where do we write to it? Because we did renaming, so we have more 34 00:02:53,733 --> 00:02:56,755 physical registers. We can't just have an identity map there 35 00:02:56,755 --> 00:03:01,056 anymore. And now, we got rid of a lot of that other 36 00:03:01,056 --> 00:03:05,957 complexity we had, but we, we added a bunch more bits to go do this. 37 00:03:05,957 --> 00:03:10,506 We now actually can store values in our reorder buffer. 38 00:03:10,506 --> 00:03:17,132 So what this is, is instead of values waiting in the physical register file to 39 00:03:17,132 --> 00:03:23,698 be committed, they're just gonna store, they're just gonna stick around in the 40 00:03:23,698 --> 00:03:28,081 reorder buffer entry. Which is, which is interesting. 41 00:03:28,281 --> 00:03:33,213 And so its gonna stick around here while it's waiting, while its pending, and then 42 00:03:33,213 --> 00:03:37,668 it's actually gonna write to the artificial register file when it gets the 43 00:03:37,668 --> 00:03:46,666 when it get committed. Okay, so we also modify the instruction 44 00:03:46,666 --> 00:03:49,659 queue. So this is gonna tell us where to go get 45 00:03:49,659 --> 00:03:54,529 the values, and we're gonna go execute. It's also gonna store the values now. 46 00:03:54,529 --> 00:04:00,452 So what's, what's interesting about this is, if you go back and look at the Thomas 47 00:04:00,452 --> 00:04:05,700 [inaudible] algorithm paper. They broadcast, commits that are 48 00:04:05,700 --> 00:04:11,968 happening, and those commits end up in the reservation station of the actual value. 49 00:04:11,968 --> 00:04:17,954 So we're actually going to store in these two source operants here, the values. 50 00:04:17,954 --> 00:04:24,624 If we get a, instruction which commits. If the instruction is pending, it's in 51 00:04:24,624 --> 00:04:27,428 flight, we can't go and just, get the values. 52 00:04:27,428 --> 00:04:30,672 Because the value doesn't exist. It's being calculated. 53 00:04:31,249 --> 00:04:38,436 And we have this dependent instruction sitting waiting for something, [ah, ]. 54 00:04:38,436 --> 00:04:44,493 [Couch], so instead, if it's pending, our source field. 55 00:04:44,493 --> 00:04:50,032 We're not going to store the value in here, but we're going to store a, 56 00:04:50,032 --> 00:04:55,336 identifier into the reorder buffer. And that, what it's going to do is it's 57 00:04:55,336 --> 00:05:00,678 going to name the exact instruction that has to complete in order for this value to 58 00:05:00,678 --> 00:05:05,021 be ready to execute. So if you think about this from sort of 59 00:05:05,021 --> 00:05:07,911 from the sort of Thomas [inaudible] perspective. 60 00:05:07,911 --> 00:05:13,085 That these sort of broadcasts coming back. And what this is going to allow us to do 61 00:05:13,085 --> 00:05:19,112 is say oh, there's a broadcast reorder buffer entry, seven, just committed. 62 00:05:19,112 --> 00:05:22,307 Or actually we probably don't even need that. 63 00:05:22,307 --> 00:05:24,886 We probably just need it to, get, stop being, pending. 64 00:05:24,886 --> 00:05:29,249 We just need to get it, to be finished, because it will then be deposited in the 65 00:05:29,249 --> 00:05:31,904 reorder buffer. We can go pick that value out, at that 66 00:05:31,904 --> 00:05:35,886 point and store it here. And then, we can basically, we have the 67 00:05:35,886 --> 00:05:40,222 other instructions that, that are renaming and executing which, go and blow away that 68 00:05:40,222 --> 00:05:42,742 value. But because we store the value here, we 69 00:05:42,742 --> 00:05:47,066 have the most up to date value for that register and we know its no longer pending 70 00:05:47,066 --> 00:05:52,016 and its valid and ready to go, at least this one, and we might have to wait for 71 00:05:52,016 --> 00:05:56,077 both of these to get ready in order for an instruction to leave the instruction 72 00:05:56,077 --> 00:06:03,001 queue. Okay. 73 00:06:03,001 --> 00:06:07,057 So the rename table, also changes a little bit. 74 00:06:07,057 --> 00:06:11,383 Not, not, not as much as the other one of the other structure. 75 00:06:11,383 --> 00:06:16,069 Structures. It's still indexed you know by the 76 00:06:16,069 --> 00:06:21,261 register. We're looking for register two, we'll say. 77 00:06:21,261 --> 00:06:25,807 It will tell us whether, Where, where to go look for that. 78 00:06:25,807 --> 00:06:30,148 There is a couple different places where it's going to tell us to go look for it. 79 00:06:30,148 --> 00:06:34,562 It's going to tell us either, it's in flight, and it's gonna put it the, 80 00:06:34,562 --> 00:06:40,044 identifier into the reorder buffer. So it's going to say when that value gets 81 00:06:40,044 --> 00:06:44,088 into the reorder buffer and the instruction transitions to finish but 82 00:06:44,088 --> 00:06:48,081 maybe not yet committed. It's gonna tell us to where to go get it. 83 00:06:48,081 --> 00:06:53,043 And that's important for subsequent instructions that are going read the 84 00:06:53,043 --> 00:07:00,067 rename table to go find the value. Or it's possible that the most up to date 85 00:07:00,067 --> 00:07:05,053 value is actually in the architecture register file, and we need to go look 86 00:07:05,053 --> 00:07:08,064 there. So, let's say the reorder buffer you 87 00:07:08,064 --> 00:07:13,006 haven't written let's say to register two in a very long time. 88 00:07:13,006 --> 00:07:17,052 And lots of other instructions execute, and the reorder buffer get's filled up 89 00:07:17,052 --> 00:07:21,087 with other things for other instructions for different destination registers. 90 00:07:21,087 --> 00:07:25,068 It's very possible that the economical place to go look for the value. 91 00:07:25,068 --> 00:07:29,095 Is in the, architectural register file and we need to track that. 92 00:07:29,095 --> 00:07:34,090 So we sort of have two bits here. It's sort of just say where to go look for 93 00:07:34,090 --> 00:07:38,011 it. Either it's in the architectural register 94 00:07:38,011 --> 00:07:43,326 file or whether it's in flight, and then if it's in flight we have to go look down 95 00:07:43,326 --> 00:07:47,760 here and if it's in flight that means that and if P is, let's say one. 96 00:07:47,760 --> 00:07:50,741 It's actually in flight and if it's, it's zero. 97 00:07:50,741 --> 00:07:54,002 Well it's in the reorder buffer waiting to retire. 98 00:07:54,002 --> 00:07:58,069 This is just gonna tell us where to go to find the actual value for subsequent 99 00:07:58,069 --> 00:08:02,083 instructions that want to go read the rename table to go find the value. 100 00:08:02,083 --> 00:08:07,032 Okay, well, we'll, we'll move on and we'll look at the eye chart here again. 101 00:08:08,215 --> 00:08:12,038 [laugh] and what's interesting about this is we no longer have a free list. 102 00:08:12,038 --> 00:08:15,033 We got rid of that structure, so you don't have to worry. 103 00:08:16,645 --> 00:08:23,088 Our renaming table instead of having actual physical registers is going to have 104 00:08:23,088 --> 00:08:27,708 reorder buffer entries. We're going, we'll call that physical 105 00:08:27,708 --> 00:08:35,082 register we'll basically merge our physical registers and reorder buffer 106 00:08:35,082 --> 00:08:39,721 together. And similar sorts of analogues happen too 107 00:08:39,721 --> 00:08:44,690 when something becomes free. But it looks a little bit different. 108 00:08:44,690 --> 00:08:48,557 So when something becomes free, we're going to actually. 109 00:08:48,557 --> 00:08:53,864 Change the, valid bits in the rename table to a zero, and that's, that's effectively 110 00:08:53,864 --> 00:08:58,933 the same thing as becoming free. And those, those analogs there between 111 00:08:58,933 --> 00:09:04,487 these two designs, they're, they're almost exactly the same from that perspective, 112 00:09:04,487 --> 00:09:08,586 from a logical perspective. But [inaudible] when. 113 00:09:08,586 --> 00:09:16,819 You be, you become free, you basically can remove it from the, the table. 114 00:09:16,819 --> 00:09:24,958 So, so how do we do the mapping from the architectural register to the physical 115 00:09:24,958 --> 00:09:31,157 register, yeah it could be random. In, in this design its a little bit 116 00:09:31,157 --> 00:09:38,246 different because you're basically going to re-pulling out of the, reorder buffer 117 00:09:38,246 --> 00:09:42,709 in order to some extent. You're going to, your physical register 118 00:09:42,709 --> 00:09:45,965 number is going to be reorder, buffer entry slot number. 119 00:09:45,965 --> 00:09:50,985 And because we want to retire in order, we're basically going to allocate from 120 00:09:50,985 --> 00:09:53,510 that in order. So it's not really random. 121 00:09:53,510 --> 00:09:57,864 It's just sort of the next reorder buffer entry. 122 00:09:57,864 --> 00:10:19,241 Let's see what are the other points I wanted to make here? 123 00:10:19,241 --> 00:10:38,808 Actually, okay. I want to, I want to make a point. 124 00:10:38,808 --> 00:10:43,938 It's around, okay so, I think what I [inaudible]. 125 00:10:43,938 --> 00:10:47,592 Okay, what I said was a little bit, little bit confusing. 126 00:10:47,592 --> 00:10:52,667 So I want to, I want to clarify this. When do you deallocate a reorder buffer 127 00:10:52,667 --> 00:10:55,328 entry? It's a little bit different than 128 00:10:55,328 --> 00:11:00,649 deallocating a physical register entry. You, you apply the same algorithm applied 129 00:11:00,649 --> 00:11:03,792 before. When you go to actually commit the 130 00:11:03,792 --> 00:11:07,453 instruction to the architectural register file. 131 00:11:07,453 --> 00:11:15,206 That's when it's becoming free. It's basically stopping, stopping being 132 00:11:15,206 --> 00:11:17,904 used here. That's a little bit different than the 133 00:11:18,089 --> 00:11:23,421 there's analogs to, to before. But we're effectively moving it out of the 134 00:11:23,421 --> 00:11:26,099 reorder buffer into the architectural register file. 135 00:11:26,099 --> 00:11:31,060 And at that point it becomes free. So, I want to actually strike what I said 136 00:11:31,060 --> 00:11:35,520 before about it, it's exactly the same. It's, it's different but subtly that when 137 00:11:35,520 --> 00:11:38,729 you go to write. When you go to actually commit the 138 00:11:38,729 --> 00:11:42,417 instruction, you're moving it to the access register file. 139 00:11:42,417 --> 00:11:47,030 And you've effectively deallocated that reorder buffer entry, and you've updated 140 00:11:47,030 --> 00:11:49,964 the, the rename table. So that's, that's, that's subtle. 141 00:11:49,964 --> 00:11:54,443 That's actually subtle there. So we're actually, when it, when it 142 00:11:54,443 --> 00:11:59,281 commits, it stops, it stops being used. This, which is different than a later 143 00:11:59,281 --> 00:12:03,020 instruction issue writing that. So that is quite a bit different. 144 00:12:03,020 --> 00:12:04,041 Sorry about that.