In this unit, we are going to discuss how we implement the VM obstruction that we introduced so far on one specific hardware platform, which is the Hack computer. Now to begin with, I would like to refresh your memory about what is the VM translator to begin with. Well, the VM translator is a program written in some high level language like Java, or Python, or any other language. And the program gets its input in other program written in VM code, VM commands like push, pop and so on. And then it process this file, it process each individual command. It breaks it into various lexical elements like push, constant, and the integer 2. And then using these lexical elements, it re-expresses these commands using assembly commands of the target platform. Which in our case is Hack. And therefore, we use the Hack Assembly Language. Now notice that what we have on the right is the output file. And one thing that I recommend that you do when you get to develop this translator is that whenever you translate a particular command, you write a comment that shows this command. This will help you debug the output of your VM translator down the road. Now naturally each VM command, which is high level in this context, is going to be translated into several assembly commands, as we saw when we talked about translation in previous units. Now, if you want to write a general purpose program that can translate any given text in the French language into the Spanish language, it really helps if you first know these two languages, French and Spanish. Likewise, if you want to write a VM translator, you have to be competent in both the source language, the target language. And you also have to know something about, where should we place the various virtual data structures like the stack and the segments on the host computer? And how are we going to translate the high level commands into the assembly commands? So with that in mind, the source language that we have to deal with is the VM language consisting of arithmetic/logical, and memory access commands, as well as branching commands and function commands. But in this particular project, in project seven, we're going to focus only on the arithmetic/logical and memory access commands. And in the next project that will be the centerpiece of the next module, project eight, we will complete the picture, and hand in also the branching and the function commands. The target of our translation is going to be symbolic Hack language. And we went through this language in module zero. And this language consists of two major commands, the A command and the C command. And that's it, that's all you need in order to translate your VM programs into assembly. Now another thing that we need to know is what is sometimes called the standard VM mapping on the target platform. Now let me explain what I mean by, you know what, let me first show you the standard mapping. And then we'll discuss why we actually need it. So basically, we have to make two decisions, how to map the VM's data structures on the host RAM, and also how to express the commands in the host language. Now the standard mapping gives you all sorts of information or conventions on how we propose that you achieve this mapping. Because think about it. If I tell you to implement a VM translator, basically you're free to do whatever you want. I can tell you, here's the RAM, do whatever you want with it. However, it is convenient and customary to propose a certain standard mapping that will ensure two things. First of all, if you agree to put the various segments in where where we advise to put it in the RAM, then you are going to conform to generally accepted standards that are also accepted by developers of other software tools that run on the same computer. So if everyone respects the same rules, these programs will not collide in the memory. And also, if you commit yourself to a certain mapping on the RAM, then we can write all sorts of test programs that also makes similar assumptions. And by doing this, the team that tests the software can be another team, other than that that actually developed the software. Which always is recommended in order to perform objective testing. So that's the purpose of the standard mapping. So here is the standard mapping of the VM on the Hack computer. Basically, I repeat things that we discussed in previous units. But I just wanted to put them in one slide, so you would have all of it in one place. We use the first five words for the segment pointers. Then the next eight words serve as the implementation of the temporary, the temp segment. Then we have several, I think three, general purpose registers. Then we have 250 or 240 something static variables. And the rest of the memory, all the way up to 2K, is going to serve as the place where we're going to host or store the stack of the virtual machine. So all these segments that we mentioned before are going to be mapped onto this RAM using the logic that you see in this slide. I don't want to read all this, it's something that you can go through yourself. And if we want to achieve this mapping, then when we write the VM translator, we have to use certain symbols. Once again, certain agreed upon symbols when we generate the assembly code that realizes the VM code on Hack. So in particular, we're going to use SP as a special label that stands for the stack pointer. We're going to use LCL, ARG, THIS, and THAT as the segment pointers of the respective memory segments. We're going to use R13, R14, R15, whenever we need to use some general purpose registers. And finally if you recall, we described in the previous unit how we are going to use special labels, specially generated labels, in order to represent static variables. The fine-line dots and running index will stand for the static variable that has the same running index. So your VM translator, when you write it in order to generate assembly code, your code is going to use these symbols. You have to be responsible for writing code that generates these labels and uses them judiciously in order implement, in order to realize the mapping that we just described. Now finally, I would like to mention that in project eight, in which we are going to implement the remaining VM commands that we haven't implemented here. We're going to extend this mapping somewhat, and add a few more conventions to it. So with that, this has been our unit on how to map the VM translator, or the virtual machine, on the host RAM and the host computer. And now we'll finally come to discuss how to actually build this program using a high level language.
