For this whole week, we explained how to write an assembler program, a program that takes assembly language code and translate it to machine language code. Now eh, when we advertised this course we said it was also appropriate for people without any program experience. I suppose that of you, the person who is now watching this unit. So how are you suppose to write any program, not to mention an assembler? Well, the answer is very simple. You can also do by hand what the program should do, and then you just need to understand what it does rather than know how to do any programming. And this is the second option for doing the last exercise that we're giving you an option to just translate by hand from assembler to machine language, from assembly language to machine language. So basically, your goal in this in this exercise is exactly the same as the goal of the people who write the program. Take as input a file in assembly language and produce as output another file in machine language which is the exact translation of the assembly language. The only difference is that programmers would write a program that does this translation, where in your case, you're going to do it yourself. You are going to take, get a file in the left-hand format and produce the file in the right-hand format that suppose to be equivalent. So let's see what exactly this means for you. We will give you on the Coursera website a few short programs written in assembly language. Each program of that form would in the file called something.asm, which we note is an assembly language program. For each of these files, let's say called Xxx.asm, you're supposed to write your own file, Xxx.hack that contains a binary machine code equivalent of the original file. Now, how are you going to write that file? You need some kind of text editor, for example, Wordpad or something like that, that just allows you to enter characters and keep it in a file. Eh, so how are you supposed to do this translation? Well, we've explained for this whole week exactly what the programmer is supposed to do. You can do the same thing that the programmer is supposed to do, and basically, produce the output that the program would have produced without actually needing to know how to program it. So again to make things a bit simpler, it's probably worthwhile to break this endeavor into two stages. The first case is the easy case where there are no symbols. Okay, so assembly language programs may have symbols, but also you, they may happen not to have symbols in them. In fact, one of the program that we give you in the, as an exercise does not have any symbols. Start with seeing how you can translate that, a program without, without any, any symbols in it. Once you have that under your belt, then you start thinking about the next stage, how to deal with symbols. And then you figure out how to eliminate the symbols. Translate the program with, that has symbols in it to another assembly language program without symbols. And once you figure out how to do that, now you can just, you know already how to solve, how to translate an assembly language program without symbols into machine language. So let's talk just very shortly about these two stages and see that you already know how to do that, okay? So in the easy case, eh, you get an assembly language program without symbols, like we see here on the left-hand side, and you're supposed to translate it to the right. How is this translation done? Well, line by line. How is the translation of each line done? Well, you break it into parts. You translate each part, exactly what was explained in Unit 6.3. And this you basically have to look up at the same tables that the program will have looked at and do the translation hand by hand. So that's the easy part. The more general, or the more difficult part is what happens when you do have symbols in your program. Then as we said, the first stage is to eliminate the symbols. And once you've eliminated the symbols, then you already know how to proceed. So how do you eliminate the symbols? Well, that we devoted all of Unit 6.4 to explain the exact conventions in the hack assembly language of what symbols mean and what kind of symbols there are. As, as you may recall, eh, you, there are basically, eh, symbols that are variables. There are symbols that are labeled in the program. And there are also some predefined symbols. And there were exact rules where each one was allocated, and how you specify them. So, this kind of translation, basically, you go again line by line, but now you have to figure out the, the, the various kind of symbols that you would need to handle. So, in some eh, cases of commands, for example, the command M equals 1 that you see here, no translation necessary because no symbols are involved. You just copy it. Of course, these are comments on the left-hand side and no comment on the right-hand side. You, as a person it's very easy for you to ignore comments because you know these are just comments. Program would've had to work a little bit to ignore the comments. In other cases, there are variables. And again, you need to go back through Unit 6.4 and see exactly how we allocated places for variables. For example, the first variable is always allocated at location 16, and then each time you see the same variable name, you have to translate it to the same location. So for example, i is the first variable that we see in this program, so whenever, and it's always allocated at place 16. So whenever we see another eh, another instance of using the i variable, you need to translate it to the same location. And the third type of thing is, eh, whenever you see how, a, a label in a program you have to figure out first what is the address of the label. And then whenever you see a reference to that label, you need to put that address. So for example, look at the LOOP label in this program. If you look at it, it's just before the command number 4 in the program, just before command at, @i. Now, notice that we have inserted eh, line numbers, and just next to the programs. And the line number, as we note, where, in which memory location, each one of these commands will be put when you actually put into memory. The logic of why, eh, the logic of how this was done is already explained in point, 6.4, and basically each command takes one position. Of course, declarations of labels like the LOOP declaration is not really a command. It is just something in assembly that the assembler should take into account and that you now translating it should take into account. But of course, it is not really a command, so we don't allocate any place to it. And of course, empty lines or comments are nothing. So, once we have that, whenever we see a declaration of the label LOOP, now we know what location it is. We need to remember it. And every time in the rest of the program that we refer to LOOP, we need to re, basically replace the symbol loop with the number, which indicates the address which is the next program, the next line after it is, in this case, address number 4. So suppose you've done all this translation. How do you know that it works? Well, the simplest kind of thing that you may think of is that, well, you just take your CPU, the CPU you designed last week. You put it into the hardware simulator, and then you load the binary version of the program that you just created, and see that it works. That is something that with the tools that you already know, and it should give you great satisfaction to see how the program that you translated actually works in a computer. We also have another tool that maybe it's not worth about to start learn, studying how to use, that actually, immediately does a simulation emulation of a hack computer, in which eh, you don't need to load your design. But it just simulates a computer in ha, in, in our software. And then you can just run your program in that eh, har, that hack machine emulator. And the third version is, we also provide ourselves an assembler tool. And our assembler tool not only can translate automatically and correctly we hope in a machine. But it can also by, when you are doing it, compare the, our translation to another translation that you provide. And then you can basically test that your translation is equivalent to our translation. So here is a screenshot of the, of the, of the assembler that we provide running when you can actually compare it to a pre-supplied program. So basically, you see on the left-hand side the eh, assembly language program. You see on the right-hand side the compare file, the file which you are supposed to provide your translation, which we check is correct. And in the middle is the automatic translation from the assembly language into machine language that our assembler does. And if our output is equivalent to your output, then you know you did it correctly. Otherwise, you did a mistake somewhere, or you've discovered a bug in our software. But hopefully there is no such bug. So that basically, finishes description of the last exercise of this course for non-programmers. And the next thing we will discuss, we will wrap up the course with the usual Perspective unit.
