|
|
|
|
Hello
Im on project 8 and doing the static test. There is class1 and class 2 functions and they both push and pop things into static. The problem is that the VM emulator does some unusual stuff that doesn't seem right (even though it probably is....)
Class1.set
pop static 0 // value goes to ram[16] as expected
pop static 1 // value goes to ram[17] as expected
Class2.set
pop static 0 // value goes to ram[18] as expe---wait... RAM[18]???? why is it not RAM[16]?
pop static 1 // value goes to ram[19]......but why?
class1.get
push static 0 // ram[16] goes to stack
push static 1 // ram[17] goes to stack
class2.get
push static 0 // ram[18] goes to stack
push static 1 // ram[19] goes to stack
----
This functionality seems much different then the one given by the book. The book simply states that ram 16 to 255 are static and that every one uses them. To me this seems like static always starts at ram 16 and you can access the other values by giving the offset value.
Can someone clarify what push/pop static is actually suppose to do?
--confused
|
|
|
Hey,
Statics are implemented as assembly lines like so: "@filename.number".
When the assembler sees an unknown label, it's supposed to allocate a memory position to it starting from address 16, onwards.
As Class1 and Class2 are different files, the @ command is different for each one. However, the eventual asm file contains all the code, from all the VM files.
So at the end, the assembler will simply allocate memory position 16 and 17 to "@Class1.0" and "@Class1.1", and 18 and 19 to "@Class2.0" and "@Class2.1".
This assumes that the order of compiled VM files, as they appear in the unified asm file is Class1 first, and Class2 second.
|
|
Administrator
|
Statics are used to implement variables in classes that are shared between all instances of that class. Other classes don't affect each other's statics. Therefore "static 0" in class Foo must refer to a different location in memory than "static 0" in class Bar. If you haven't done object oriented programming, this will make more sense when you get to chapter 10.
--Mark
|
|
|
@david bar
That tip helpped make the static stuff work properly. thanks
@cadet
I'm fluent in C/C++/python/C#
I know what static means in an object oriented context and it means that within the same scope
that variable will retain its value through out the life of the program. If the variable was declared
within the scope of a function, then that means everything inside the function will be able to access
it and set/get it and know that its contents will not be distorted upon exit (like it does when things are stored on the stack). The same goes for a class. if the static was declared inside the class definition, then all the functions inside of it would be able to access it. Multiple classes that access that static variable would
be accessing the same value and in essence becomes shared.
However, my confusion stemmed from chapter 7-8's definition of static. Following its instruction, it doesn't really describe how to do static completely. Its more like a hint then an actual description. I wasn't sure what scope I was suppose to be looking at. Since static 0 (aka R16) is used in the function "class1.set" I thought that only "class1.set" would have access to the R16. I did not realize that this static was for the
scope of the CLASS not the function.
@all
So in conclusion, thank you for all your help. I just got to be careful with this book since I will have to use outside knowledge/info to fully understand it.
|
|
|
This post helped me. Thank you.
Yet I feel your suggestion doesn't match the behavior of the VM Emulator completely.
If I ran, for example, 'pop static 3' in Class1 and 'pop static 0' in Class2, these variables would be mapped to RAM[19] (expecting pop static 0-2 to come as well) and RAM[20], respectively. Try it!
Following your method; that is, using the .asm code @Class1.3 and @Class2.0, would map these variables to RAM[16] and RAM[17], respectively.
I believe this is because this 'expecting' is not created -- nor do I know how to (re-)create it.
Shimon!
|
|
Administrator
|
Please post some test code that shows this problem.
I tested with the following 3 files and Class1.static 3 ends up at RAM[19] and Class2.static 0 ends up at RAM[20]
// Main.vm
function Main.main 0
call Class1.f 0
call Class2.f 0
push constant 0
return
// Class1.vm
function Class1.f 0
push constant 103
pop static 3
push constant 0
return
// Class2.vm
function Class2.f 0
push constant 200
pop static 0
push constant 0
return
 --Mark
|
|
|
My .vm code looks very similar to yours and produces the same result as yours in the VM emulator, which, I think, is what I stated in my post. Hence, I think there is no need to post .vm code.
The 'problem', if there is one, relates to the method proposed in this thread for translating 'pop/push static i' commands from .vm to .asm code.
If I have understood the suggestion correctly, and using your code as an example, the 'pop static 3' command located in 'Class1.vm' is implemented in .asm code as something like:
@SP
A=M
D=M
@Class1.3
M=D
The CPU emulator interprets the label @Class1.3 as @16, which means the command writes the variable to RAM[16].
|
|
|
I'm not sure what you think is the problem. Do you mean that the VM emulator would use one address for the static variable (like 19), while the code translated to HACK will use another (e.g. 16)? This is not a problem. The specification doesn't tell you how to map the variables in RAM. The HACK assembler will assign the addresses based on when it encounters a new name, so if you rearrange the compiled classes, you'll get a different mapping, but still it will be the same program.
Or do you mean that the variables Class1.3 and Class2.0 should both map to the same address? They shouldn't. They are different variables from different classes and should be stored in separate RAM locations.
|
|
|
Hi Mark,
I was started to get confused trying to track with this thread. I needed clarity about the static variables.
Thanks for the responses as it really helps me a lot to understand.
|
|
Locked
