Static Segment naming convention

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Static Segment naming convention

yoav
I am not sure I understand how to deal with the following spec:

"Each static variable j in file Xxx.vm is translated into the 
assembly symbol Xxx.j. In the subsequent assemblyprocess, 
these symbolic variables will be allocated RAM space by the 
Hack assembler."

For example, in the StaticTest.vm exercise, I used variable 'StaticTest.8' for the 'push static 8' vm command. The CPU emulator assigns it to RAM(16) and not RAM(24) as one might naively assumes.

Please clarify the rationale behind this spec. 

Thanks


Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
yoav wrote
I am not sure I understand how to deal with the following spec:

"Each static variable j in file Xxx.vm is translated into the
assembly symbol Xxx.j. In the subsequent assembly process,
these symbolic variables will be allocated RAM space by the
Hack assembler.
"

For example, in the StaticTest.vm exercise, I used variable 'StaticTest.8'
for the 'push static 8' vm command. The CPU emulator assigns it to RAM(16)
and not RAM(24) as one might naively assumes.

Please clarify the rationale behind this spec.

Thanks
Your translation is correct.

StaticTest.8 is a symbol name, handled the same as abc.xyz, no arithmetic is implied. Remember that the assembler assigns RAM addresses to unknwn symbol names sequentially starting at 16.

Eventually you will be translating multiple VM files into a single ASM so you will have static variables from multiple classes, and every one needs to end up with a unique symbol name.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

ybakos
In reply to this post by yoav
yoav, as Mark asserts above, your thinking is correct. However, the example you've created is contrived. In valid VM instructions, which will be generated by a proper compiler, you can assume that StaticTest.0 - 7 would be defined before StaticTest.8.

Furthermore, a variable called StaticTest.8 doesn't necessarily translate to "static 8". But this is something that will be revealed as you progress with the VM and compiler. Good luck!

Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
The statics won't necessarily be in numeric order, depending on how you write your translator. My translator defines the numeric ID in the order the static variable declarations appear, but the first appearance of the symbol in the assembly output is the first time the static variable is used.

My normal coding style initializes the statics in the order they are declared so the IDs are usually in numeric order, but not guaranteed.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

Koen_Be3840
It is a bit confusing because when you run the StaticTest.vm, it pops

static 8 in RAM[24]
static 3 in RAM[19]
static 1 in RAM[17]

it should be in order of appearance

static 8 in RAM[16]
static 3 in RAM[17]
static 1 in RAM[18]

An error in the VM Emulator?
It got me going for 30min.

Koen
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
I don't see this as an error in the VM emulator. Since the VM specification doesn't define in what order VM files in a directory are to be processed, there is no guarantee where any particular static variable will be located.

Also, the assembler doesn't require that undefined symbols be assigned addresses in source code order. Another valid approach would be to add all symbols to the symbol table during pass 1. Then between passes 1 and 2, traverse the symbol table, perhaps in alphabetical order, and assign addresses to any symbols that do not already have addresses. Then pass 2 doesn't need to do anything special for symbols; they already all have addresses.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

Koen_Be3840
I don't mean error as an error in the software. I mean it as a bad example. What happens in the VME does not seam to respect what we've learned about the Assembler.

No disrespect

Koen
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

Albert G
I assume the names of the variables do not have to be "xxx.i" where "xxx" is the name of the source vm file. In my implementation I use "Vn.i" where "n" is a sequential number I increment for each vm file compiled in a single run.

So static variables for the first file in the run will be "V1.8", "V1.3" etc. Those produced by the second file will be like "V2.3", "V2.2" etc.

Does anyone think this would cause trouble later on ?

Albert
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

sgaweda
In reply to this post by Koen_Be3840
Koen_Be3840 wrote
It is a bit confusing because when you run the StaticTest.vm, it pops

static 8 in RAM[24]
static 3 in RAM[19]
static 1 in RAM[17]

it should be in order of appearance

static 8 in RAM[16]
static 3 in RAM[17]
static 1 in RAM[18]

An error in the VM Emulator?
It got me going for 30min.

Koen
I'm glad to see I'm not the only one that was confused by this. What is being said in this thread is that the proposed implementation in the chapter (using Xxx.n) results in the three values static 8, 3, and 1, being assigned to RAM[16], RAM[17], and RAM[18] respectively. Your test, however, uses the numbers 8, 3, and 1 as an offset from RAM[16] and places them in RAM[24], RAM[19], and RAM[17] respectively.

In order to arrive at the correct test output I simply used RAM[16] as my base for static and used the numbers following static as an offset value and was able to output the same output as the test. However, this has meant that I haven't actually implemented the suggestion in the book. If I had implemented the solution the way the book suggest it, I would have arrived at the same result as the gentlemen in this thread. I would have three variables assigned to RAM[16], RAM[17], and RAM[18] and would fail the provided test.

I suppose what I want to know is how exactly did the VM Emulator implement static? Does it allocate a block of memory for the static variables of each .vm file and refer to that base address of that block?
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
sgaweda wrote
In order to arrive at the correct test output I simply used RAM[16] as my base for static and used the numbers following static as an offset value and was able to output the same output as the test. However, this has meant that I haven't actually implemented the suggestion in the book.
If you implement "static n" as RAM[16+n], then you will fail the 08/FunctionCalls/StaticsTest test. That test validates that Class1.vm's "static n" refers to a different RAM location than Class2.vm's "static n".

I suppose what I want to know is how exactly did the VM Emulator implement static? Does it allocate a block of memory for the static variables of each .vm file and refer to that base address of that block?
Something like that.  You can download the Java source code for the VM Emulator and read it if you want to know exactly how it works :^)

I did a bit of experimenting with 08/FunctionCalls/StaticsTest, and it looks like this is what the VME is doing:
  1)  Let STATIC_BASE = 16
  2)  Read a VM file, keep track of the largest static index used (MAX_INDEX)
  3)  All "static n" references in this VM file refer to RAM[STATIC_BASE+n].
  4)  Let STATIC_BASE = STATIC_BASE + MAX_INDEX + 1
Repeat 2-4 for remaining VM files in the directory.

I assume the VME does this so that it can reuse its memory segment UI code for the static segment. It is indeed unfortunate that this ends up implying the use of RAM[16+n] when reverse engineering with StaticTestVME.tst.


I'll need to think a bit about the best way to have StaticTest.tst check that "static n" is not implemented as RAM[16+n].

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

sgaweda
cadet1620 wrote
Something like that.  You can download the Java source code for the VM Emulator and read it if you want to know exactly how it works :^)

I did a bit of experimenting with 08/FunctionCalls/StaticsTest, and it looks like this is what the VME is doing:
  1)  Let STATIC_BASE = 16
  2)  Read a VM file, keep track of the largest static index used (MAX_INDEX)
  3)  All "static n" references in this VM file refer to RAM[STATIC_BASE+n].
  4)  Let STATIC_BASE = STATIC_BASE + MAX_INDEX + 1
Repeat 2-4 for remaining VM files in the directory.

I assume the VME does this so that it can reuse its memory segment UI code for the static segment. It is indeed unfortunate that this ends up implying the use of RAM[16+n] when reverse engineering with StaticTestVME.tst.


I'll need to think a bit about the best way to have StaticTest.tst check that "static n" is not implemented as RAM[16+n].

--Mark
Thank you for the speedy response. I've decided to go with similar implementation to how the vme executes the code, but I'm still confused about how this relates to the suggested implementation in the book. The book suggests labeling each static variable using a naming convention of Xxx.j where Xxx is the name of the vm file and j is the index given for the static variable. I understand the compiler won't ever give a situation where it's defining the 8th variable without defining the 7th variable, but to implement the changes required to satisfy StackTest.tst I still have to deviate heavily from the proposed implementation in the book.

If the specific test in StackTest.tst isn't ever going to occur once we've written our compiler, why are we testing for it? As a corollary, if the vme implements this solution differently, why doesn't the book suggest that implementation instead of the Xxx.j approach to solving this particular resource allocation? I'm having trouble understanding what use case this particular test satisfies.
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
sgaweda wrote
... to implement the changes required to satisfy StackTest.tst I still have to deviate heavily from the proposed implementation in the book.
I don't understand what doesn't satisfy StackTest.txt when you use symbolic names for the static variables.  StaticTest.tst is not looking for anything in RAM locations 16+1, 16+3 or 16+8. It should not care where in RAM the static variables are stored. As long as "push static n" retrieves the same value as was written by "pop static n", the computed value left on the stack will be correct and the test will pass.

If you would like, I can send you the StaticTest.asm that my VM translator generates that passes the test, using symbolic names.
... why doesn't the book suggest that implementation [the VME's behavior] instead of the Xxx.j approach to solving this particular resource allocation? I'm having trouble understanding what use case this particular test satisfies.
To allocate a static segment the way the VME does requires that your VM translator must keep track of the maximum segment index used as it translates each VM file and manage the static segment base address as it processes sequential VM files.

The code to just write ClassName.n is simpler. (It also matches how the VM translator that generated 06/Pong.asm handles static variables.)

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

sgaweda
I understand now! I was under the impression that I needed to effect the same result as the vme and didn't realize that the test doesn't even check to see where the variables were stored, just that the final output is correct. I've already implemented it with the same logic as the vme, but will likely rewrite it now that I understand the proposed implementation still passes the test. Looking forward to tackling project 8 now as well.
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

sgaweda
Mark, I'll take you up on that offer to send me your StaticTest.asm I'd really like to see how my generated code compares to yours. How can I send you my email address?
Reply | Threaded
Open this post in threaded view
|

Re: Static Segment naming convention

cadet1620
Administrator
sgaweda wrote
How can I send you my email address?
You can send text email directly to forum posters using the "More->Reply to Author" dropdown on any post.

--Mark