|
|
|
|
This post was updated on .
"Suppose that the file Xxx.vm contains the command push static 3. This command can be translated to the Hack assembly commands@Xxx.3 and D=M, followed by additional assembly code that pushes D’s value to the stack. This implementation of the static segment is somewhat tricky, but it works."
At first, when I read the book, it seems working. But when I try to implement the project VM translator, I have a question.
push static 3 (get the value of static segment at index 3 and push it into the stack).
but the recommend way of mapping to hack assembly doesn't make sense.
@Xxx.3
D=M
Then push to the stack
but the first command doesn't tell the assembler the index, 3 , assembler considers "Xxx.3" as a variable which is at memory 16 not 19.
So does that mean the index doesn't matter, if yes why not push static 0 instead of push static 3?
|
|
|
Static segment contains class-level variables. That is, variables that are shared by all instances of the same class. Your first variable will be with index 0, second one with index 1, and so forth. If you push static 3, it means you are pushing the value of the 4th static variable. In that sense the index does matter.
On the other hand, nothing stops you from making your last static variable be at index 0, last-but-one on index 1 and so on. It would be a bit harder to map and to debug, but it would still be valid way to compile your code. In this sense the indexing doesn't matter (as long as it's 1-1 and consistent).
The VM translator should not care about the actual address assigned by the assembler. So 16 or 19 does not matter. What's more, suppose you have other class Yyy, which also has static variables. In assembly they will be named Yyy.0, Yyy.1, etc. Depending on which file the VM translator processes first, its static variables will use lower addresses in the HACK code.
|
|
|
As you explained "push static 3" means you are pushing the value of the 4th static variable.
but the assembly,
@Xxx.3
D=M
then push it,
doesn't know about the 4th variable. It just allocate a memory in RAM starting from address 16, so it may not be the 4th variable. If the @Xxx.3 instruction is what the assembler gots first, it allocates on address 16, which is the 1st element.
|
|
Administrator
|
Henoktes722 wrote
As you explained "push static 3" means you are pushing the value of the 4th static variable.
but the assembly,
@Xxx.3
D=M
then push it,
doesn't know about the 4th variable. It just allocate a memory in RAM starting from address 16, so it may not be the 4th variable. If the @Xxx.3 instruction is what the assembler gots first, it allocates on address 16, which is the 1st element.
The authors addressed this in the text, but it is certainly not something that is obvious from a superficial view. While some of the memory segments have physical implementations that closely match the notion of the index being directly related to the offset of that variable within the address space of that segment, some are not. This is not really a requirement for ANY of the segments -- there is nothing that relies on index 5 being immediately adjacent to and between indices 4 and 6 within memory. If it happens that doing that makes implementing the required behavior simple, then that is a strong argument for organizing it that way. But if there are other considerations that make a different approach more workable, then we need to avoid letting ourselves get boxed in by trying to insist on imposing a behavior that is not actually required.
The constant segment is a case in point in which we only have a virtual segment that is implemented such that it has a desired behavior, namely that the value stored at any index within that segment is equal to the index.
The static segment is another segment in which we have a desired behavior, namely that the index within the static segment maps to a unique memory location that is used only by that VM file, that the lifetime of that variable is the entire life of the program, that all functions within that VM file can access it, and that the same index within the static segment but in different VM files maps to different variables. How we implement that behavior is up to us.
The implementation of the static segment relies on exploiting the assembler's specification regarding how variables are allocated. This allows us to combine the name of the file with the index to create a globally unique variable name knowing that, as a result, the assembler will map each such variable from all of the files in the VM program to unique memory locations that will persist throughout the life of the program.
|
|
|
Thank you for your clear explanation. So order doesn't matter, what only matters is uniqueness.
What makes me vague was, the VM Emulator allocates at the index position, like pop static 3, sets the value of the static segment at index 3.
|
|
Administrator
|
Henoktes722 wrote
Thank you for your clear explanation. So order doesn't matter, what only matters is uniqueness.
While order does not matter, it is going too far to say that ONLY uniqueness matters. There are other behaviors that must be implemented as well. For instance, the local segment must have the behavior that each function has it's own local segment while the static segment must have the behavior that all functions within a VM file share the same static segment. Also, while there is no requirement that the local segment persists from one call of a function to the next call of that same function, it IS required that the static segment persist (i.e., remain in existence with intact values) throughout the life of the program.
What makes me vague was, the VM Emulator allocates at the index position, like pop static 3, sets the value of the static segment at index 3.
Keep in mind that the VM is virtual machine -- it is a description of a processing machine that has a certain instruction set and architecture. The VM emulator operates at the level of that machine and in that machine each segment can be thought of as a set of memory addresses identified by their index -- that we choose to render them on a screen as though they are physically located next to each other is merely for our convenience. If you do pop static 3, yes, it sets the value of the static segment at index 3 to whatever happened to be on top of the stack, but it makes no assertion as to where static 3 is located relative to any other variable -- only that all references to static 3 within a given VM file will refer to the same memory location while any reference to static 3 within any other VM file will refer to some other memory location.
The VM emulator is completely agnostic as to how the VIRTUAL machine is implemented on the underlying hardware, be it the Hack or an Intel x64 or an ARM or a PIC-32. That's an issue for the VM Translator.
|
|
Locked
