 Welcome to the Artificial Life Advance class. This is T-minus 6, counting down to January 3rd, 2023, when we're going to have all this stuff working, we shall see. Last time, we had just started the growing diamonds running on the T2 tile grid. They had a couple of days on it last time. This is how it went. So, longtime viewers will recognize that as a crash storm when something goes wrong in the communication between the tiles, and one of them, you know, gets out of sync with the others, and the code is just not robust enough to figure out what to do about that. So, one of them goes down, and that takes the other ones down with it, and the whole thing went down. And I have another clip, a little montage of my thinking and what I ended up trying to do about it. Most distributions don't actually require the tile to reboot, but when you do the Linux level stuff, it does. And then I just basically stuck a growing diamond in just about every tile, figured, you know, what the heck, let them slug it out, and that's what they've been doing. Same thing, except they're much smaller because I put a lot more tile, a lot more diamonds in there to start with, with a similar pattern. At this point, it's a stress test, trying to get as many conflicts going, as many things jammed up, stuff going on, see what's going on. And there are a number of problems, although the crash storm, which is my big worry, so far we haven't seen it, but then it took like two weeks last time. Now, I mean, for example, there's still little issues in various places where things aren't moving, even though they technically could. How's it going to come out? We'll find out whenever we find out. So, you know, I'm a warrior, I worry about a lot, I worry about everything. So, and you know, one of the big things that I've been worrying about for years, I think that's true, is this, intertile packet failures, that the underlying mechanism won't be robust enough to handle it, and then the software level laid on top of it won't be robust enough to handle that, and so on. So, we shall see. So, that one happened. The interdiamond deadlocks, you know, we already have that. I think it has to do mostly with when the growing diamonds grow. Sometimes they really don't have enough space around them, or they did when the signals came in, but by the time the growth wave gets back out there, something has changed and they sometimes get jammed and things go a little bit wrong. Seems like maybe they need like, you know, a little cilia or something so that they could detect even further before deciding to grow diamond crashes, and then all these other things. You know, one of my big worries is this whole thing's going to be so slow that even if it works, we won't have enough runtime weeks, months, who knows, on the grid to actually get from the ancestor to grandchildren before, you know, January 3rd is coming, gone by months, need more time, need more space, need more current, and just, you know, etc. You know, so I don't know if this is going to work. We'll find out. Okay. And here we are, T-minus 6. We're supposed to have HC-3 sequencer a month ago. We did not, but we're going to have progress on that today. So instead of the state machines that we're supposed to have, we have HC-3 sequencer. So loop reshaper demo didn't work on it. HC-3 sequencer design did more than just design. We'll have a demo. So we're doing all kinds of parallel stuff, trying to get everything to be distributed and go all opportunistic all over the place. But now we're at the point where we deliberately want to have a serial thread of computation in a certain spot. And sequential computing is very powerful. It's what traditional computers do, of course, but it's also very fragile because the whole point is you do different things in the same place. So in fact, you're erasing what you did on the previous step when you go in with the next step, except for the little bit that you put out somewhere else. So what is a central processing unit without random access memory? It's kind of a Zen coin. So what I've come up with, I'm calling it the diamond sequencer, and it's a little bit awesome. I think we shall see, it's not like I've tried to program any of this stuff yet, just trying to get the infrastructure built so far. So here is a traditional CPU from Wikipedia, from Lamtron's picture. It's got a control unit that runs everything else, registers, that's temporary storage, the combinational logic, that's the part that does 2 plus 2 equals 4 and so on. And then it's got main memory, which is RAM, input from the outside world, output back out to the outside world, and main memory feeds instructions up to the control unit. And the movable feast machine, what we're using doesn't have main memory, kind of the point. The text in the Wikipedia page, a key component common to all CPUs, is the program counter, which tells you at any given moment which piece of main memory is supposed to go and be the instruction. And so what are we going to do? Don't have main memory, don't have a program counter. So still we know that we're going to need some kind of input from the outside, some kind of temporary storage. The question is where are we going to get the instructions from and how are we going to get them to the control unit without a program counter or main memory? And here's what I came up with, the diamond sequencer. It used to be HC3 sequencer. So this is part of a regular diamond. And this is the root of the diamond. So that part would actually be dead center if we had this thing growing out all the way. I put the diamond sequencer immediately north of the root, although it doesn't have to be there. This way it's in sort of convenient communication distance. If the instructions want to say something to the root like, oh, maybe you should increase your size a little bit or whatever. I put in these cross lines just to emphasize the four quadrants around the diamond sequencer because that's where we're going to put all of the other pieces of the CPU instead of trying to put it inside the diamond sequencer itself. So in all of the demos with the diamonds and the growing diamonds that we've seen in the last several updates, it's been one big wiggly yellow and blue lines going all over the place. But now we're going to actually have four separate loops that come through and they all meet at the diamond sequencer. And the idea is, is that the diamond sequencer is just a middleman. It doesn't really have hardly anything itself. And what it does is it assigns functions to the chains. So this one down here is going to be the instructions. And here's the temporary storage, the registers, the input, the output, and so on. And so the idea is, what's the program counter? Where are we going to go to find what instruction is next? It's whatever atom in the pocket chain happens to be right here next to the diamond sequencer in the quadrant that has instructions in it. And when an atom pocket chain, a suitable type finds itself there, it will say, oh, it's my turn to execute. I need to read from the input. And it doesn't even necessarily know what quadrant the input is. It consults the diamond sequencer, the middleman knows. That's the idea. And the beauty of this is that, you know, since the whole point is, we're giving up on random access memory. So we want to have things live where they are needed. We want to have them laid out in space in a way that's what we want them to do. So if we had stuff over here that was input that we read some input, and we now want to do some instructions from it or something like that, what do we have to do? We have to move them from over here down here? No. So the other thing the diamond sequencer does is it has a little 8-bit array saying what is the current assignment of functions to quadrants. I'm calling that a grip saying each of the four quadrants has this function now. And you can change the grip. So there it's 0, 1, 2, 3. That's the default setting. But we change it and now the instructions are coming from up here. Over here is registers input output and so forth. I don't know what it's going to be like to try to program this stuff. It's going to be crazy, but it's actually seems quite powerful, right? You could read a few instructions off the front of the instruction stream say and make copies of them in temporary storage and then change the grip to start executing those with the rest of the program, for example, now being the input, we shall see. Change the grip again and so forth. So the important point is that what really the diamond sequencer is just the control unit, all the registers input output combinational logic is all delegated to the chains and this guy just says when you're here, you're part of a program. So processor is rounded at the point. So okay, let's try to take a quick look at it. All right, so I've got this setup. See, here's the diamond sequencer right here. So we've got some custom rendering code. So at the moment, white, that's the instruction stream is to the northwest, red, that's output is northeast green is input, that's the southeast and the temporary storage registers is southwest. And the way my little test program works is the pocket chains that we have around it. Let's just let it run. Okay, well, it's working. So what this program does is the red ones in these in the pocket chains are the active ones, the ones that know about this little program. And when they discover that they are in the instruction pocket, which for example, this one is now here, because the process the diamond sequencer has been re gripped. So that instruction caches up here, when this one gets a chance to go, all it does is rotate the diamond sequencer grip on 90 degrees clockwise. And so there it is. And you see the the red ones flash white, they're a little bit late that they flash white when they realize that they were instructions. The reason that they're late is because we don't see them as white at the moment. We see them the next time they get displayed. And look at this. So it's doing a completely pointless program, but it's doing it in a way that's pulling instructions from all different quadrants. And it's doing it at the exact same time that the entire thing is moving and growing and living its little life. All right, we're starting to get there. All right. So that's the main thing we've got. Here is the title card for this time, engineering a new serial computer. Diamond sequencer. I give you diamond sequencer. We'll see. Again, I'm kind of excited about it now, but we'll see how I feel once I've tried to actually program this thing. In other news, the September computing up is out. Peter Norvig is an absolute legend in AI. We had a good conversation if you might be interested in checking that out. The next update will be September 27th. It will be T minus five and counting. The goal is to have a self-copying program demo. We'll see if that's even in the realm of possibility. We may need some loop reshaping stuff in order to get the copy out of the way. I have no idea how this is going to work, but if we can get that going, that will get a lot of the state machine stuff. We might be sort of be able to get back on track to catch up where we were supposed to be according to the spreadsheet. And again, have some fun. I've been trying to do this sequencing for a long time, and I've had a lot of hard starts and misfires and so on. And this may still misfire too. I don't know, but it feels right. It's got the Stigmergic, lay it out, use it as it lays, build everything so that it's where you need it, when you need it. We shall see. Thanks so much for taking a look. However you found this, I hope to see you again.