 I'd first like to talk about why I've created a simulator. Now, it's all good and all, we have this architecture and we say we've written a compiler for it, but we want to see code executing, staring at assemblies just not good enough. And the way that we do most of our testing early on in a project is through GCC's regression. And typically this consists of several tens of thousands of small C programs that have represented corner cases in the compiler over the years. And generally any good port of the compiler should be able to compile them all without blowing up. And the way that these are executed is through a tool called Dejauguinu. Dejauguinu is a generic given a program compiler to run it somewhere tool. And for deeply embedded targets like ours, this is typically done through GDB, which is the debugger. GDB then talks to your hardware through what's called a GDB server, typically via TCP or some other socket, and over a communication via RSP. And in your GDB server you do whatever you need to do to respond to the query, write this piece of memory, give me back the registers. So this could be say Dan's FPGA implementation from before, or alternatively my simulator which I will move on to. As I said a moment ago Dejauguinu is very generic. It doesn't need to talk to GDB, it's just a very typical way of doing it. An alternative way this is done is by talking to the simulator itself directly, and really as far as software is concerned these two parts are exactly the same. And I will talk about how this is designed at the moment. So to start with as an aside, I want to go into a bit of detail into how instructions exist in a compiler, or more specifically LVM. When porting LVM, LVM has this language called table gen, which you hopefully can see on the screen, which is a language for describing classes of instructions, what they do, and their encodings. So you can see here that I have this class of instructions, it's 32 bits long, and that register RD, the destination register, is split up into two chunks between bits 8 and 6 and bits 24 to 22. And throughout porting your compiler, you'll build up hierarchies of these classes, eventually getting down to the point where you can write small declarations like this, which say I have an instruction called add. It is a ALU operation, so it inherits the ALU opcode stuff. It has opcode 1 in your assembler you type add in order to generate it, and for the compiler's purposes, it is an add. And as part of building your compiler, you take this definition file, which could be several thousand lines long depending on how many instructions you have, and the compiler spits out multiple things. For the compiler as itself's sake, the most important thing to it is it generates an instruction selector. So the way that many compilers work is it produces a graph of your programme and then pattern matches your instructions to the things it has and essentially replaces this graph with a graph of your instructions, and then moves on to later stages. But being that I've defined all these bit patterns here, it also generates a couple of other tools for you, the first of which being an instruction encoder so that you can use your compiler as an assembler. And also, if you can go one way, presumably go the other, it also generates you a disassembler. And being that I've already created this file and I already have a disassembler, one of the first pieces of building my simulator is to take binary and turn it into instructions, so I want to reuse this disassembler I've already created. Now, my simulator is your typical fetch decode execute loop just continuing until the end of time. And it needs some stent for keeping track of the registers and the programme counter, and also some sort of control for talking to the outside world because presumably it's all good just seeing that your processor is busy but you may want to have some more interactive interaction with it. So, and I'll go through these two bits in turn. So, the first, the fetch and decode bit is almost given to you for free by the compiler. For the disassembler to work, it has an interface which goes given a blob of memory and an offset into that memory give me an instruction. So, I use this up here in order to get me an instruction. The only subtlety being everything inside the compiler is byte-addressed and our instruction is a word-addressed, so I need to shift the programme counter by one to give me a useful offset for the compiler. And assuming I'm given an instruction, I can then calculate, and one of the things you get back from the compiler is how big the instruction is just decoded is, so you can calculate what the next instruction should be assuming that you don't branch. So then all you have to do is execute your instruction right back the programme counter for where to next fetch the instruction. I just continue to do this. One addition is this get instruction function can return false if what is in memory is not a valid instruction, and presumably in that case it's more useful for the simulator to stop than to just simulate nothing and just continue doing who knows what for the rest of time. So, the execute element of this is takes this instruction object which has been given to me by the disassembler, and I just need to extract the operand fields from it. One of the nice elements that the LLVM disassembler has given me for free is that, so AAP has these two variants of the register-add instruction. The short variant which can access only the first eight registers and a longer version which can access all 64. Now, to the disassembler, it just generates me an instruction that says the first operand is register 3, the second operand is register 4, for instance, and it has already done that mapping for me, which means I can save a bit of time for all purposes just treating these as the same instruction. So, my simulator takes register A for an add, takes register B, adds them together, and stores a result back. And in addition to this, I need to care about overflow bits for arbitrary precision math, for instance. So, I do a small test to check for overflow and save that back in the simulator state. And then say that the instruction is done. One element of the instruction container is this get-op code field, which returns me an enum for my instruction. So, execution is essentially one long function with blocks of code similar to this. The final piece of the simulator is how to talk to the outside world. Now, we've done something similar to what OpenRisk does, which is where it has a knob instruction where the operand does something special in the simulator. We've extended that a little bit by also adding a register so that you can have more precise control over what you want to execute. So, for instance, so here we do the same load register and we get the immediate from the instruction. And based on the immediate we do an operation, so knob three will print a particular register to the screen. Knop two will tell the simulator, I have finished execution. Please stop. Knop one we have as a specific, as an actual knob. And knob zero we treat as a breakpoint. This is useful as the encoding for knob is all zeros. So, if in the simulator all memory is zero, initialize, and I go branching off into the middle of nowhere, I know I will stop one instruction later because I will execute a breakpoint. And now, hopefully, I can show you everything working. So, on the left-hand side you will see a game of life simulation running in the simulator. And on the right you see a trace from a execution of a game of life in the simulator. So, if I pause that, you can see that I am executing add instructions and that I am reading R59 and R57 and storing the result back in R57. And various instructions here, making use of the simulator knob to print out to the screen so that you can see this here. And yes, does anyone have any questions?