Where THIS and THAT are set

[cyboman]

I understand why we need to push this and that on the stack when one function calls the other but I can't figure out where thier values are set? A small picture on the right side of page 160 says that this, that, pointer and temp are undefined upon entry, so what sets those values and how do we make sure that when we go from one function to another we don't overwrite the heaps of each function?

[cadet1620]

cyboman wrote

I understand why we need to push this and that on the stack when one function calls the other but I can't figure out where thier values are set? A small picture on the right side of page 160 says that this, that, pointer and temp are undefined upon entry, so what sets those values and how do we make sure that when we go from one function to another we don't overwrite the heaps of each function?

The VM translator does not need to do anything special to initialize this or that. The Jack compiler generates code that handles them.

When a function is called that manipulates an object, the compiler generates vm code that passes a pointer to the object as an extra parameter. The generated code for the called function uses this extra parameter to set THIS.  When the compiler needs to dereference a pointer to something other than the current object, it uses that.

--Mark

[cyboman]

Thanks, I see what is going on here. But now I'm confused about processing of multiple .vm files. From this (http://tecs-questions-and-answers-forum.32033.n3.nabble.com/Order-of-processing-for-multiple-vm-files-td4024915.html#a4024982) post I understood how we handle static variables. What I don't understand now is when Sys.init is called during multiple processing of .vm files? Do I call this function at the beginning of processing of each .vm file? If yes then it seems like each file is its own program and there is no point in the ability to handle multiple files. If no then how do we combine multiple files into a single program?

[cadet1620]

cyboman wrote

What I don't understand now is when Sys.init is called during multiple processing of .vm files? Do I call this function at the beginning of processing of each .vm file? If yes then it seems like each file is its own program and there is no point in the ability to handle multiple files. If no then how do we combine multiple files into a single program?

During project 8 you will add "bootstrap" code to your VM translator. This code is written to the .asm output file before any .vm files are processed. The bootstrap code initializes the stack pointer and calls Sys.init.

You will learn how the Jack compiler works in chapter 9. Each object class is contained in its own source file and is compiled into a separate .vm file. All these .vm files, and the OS .vm files, are then combined by the VM translator into the program's .asm file.

--Mark

[cyboman]

The question that I had is somewhat different. Let's say I have two files, file1.vm and file2.vm. When I process them and generate a single directory.asm file, do I insert a call to Sys.init in each of them or I just concatenate file1.asm and file2.asm to generate directory.asm? I.e. do I do this:

directory.asm = code for Sys.init + file1.asm + fil2.asm

or

directory.asm = code for Sys.init + file1.asm + call Sys.init + file2.asm

[cadet1620]

cyboman wrote

The question that I had is somewhat different. Let's say I have two files, file1.vm and file2.vm. When I process them and generate a single directory.asm file, do I insert a call to Sys.init in each of them or I just concatenate file1.asm and file2.asm to generate directory.asm? I.e. do I do this:

directory.asm = code for Sys.init + file1.asm + fil2.asm

or

directory.asm = code for Sys.init + file1.asm + call Sys.init + file2.asm

You want
    directory.asm = code for Sys.init + file1.asm + fil2.asm

--Mark

[Christian Albers]

Hi,

I think I wasted two days worth of time to figure out what to do with the "this/that" segments when I did chapter 8 (in fact, I am still working on chapter 8, so the two days came to an end about 30 min ago). The function call convention says the base addresses of the "this/that" segments of the caller need to be saved on the stack, but chapter 8 nowhere says how to generate the base addresses of "this/that" of the called function. Since I had no idea what those will be doing later on, I figured they are similar to the "local" segment, only on the heap. So I passed the maximum offset of this and that of the caller to the called function, to calculate the new base addresses ... while ignoring the nagging feeling I'm doing something wrong here. Turns out the nagging was right, because out of frustration (I re-read chapters 7 and 8 over and over again) I fast forwarded to chapter 11 to look the usage of "this/that" up.

I think it would have been good in chapter 8 to include a sentence like "Don't worry about handling new this, that and pointer segments upon subfunction entry, this will be left to later projects (Jack compiler)", or something like that. The meager sentence in the box on page 160 is easy to miss, and giving a reason why those segments need no treatment would make it easier to keep in mind not to try this at this point.

Anyway, needed to vent, "Elements" is still a great book! Love it.