Static variable handling

[mng12689]

Hello,

In "Unit 5.2 Handling Variables", it states that the class-level symbol table can be reset each time we start compiling a new class. However, static variables are global in the sense that they are stored in a single contiguous block of memory, which makes it seem like if we had 2 classes, A and B, both with static variables x and y respectively, x and y could not be both recorded as "static 0" in their respective tables. Is this true? When we "reset" the class-level symbol table, do we still need to maintain some counter for the static variables across classes? I'm not sure how else we could compile classes completely in isolation without having static variables collide in memory.

P.S. I ran the Pong test which is supposed to test static variables. It runs fine without maintaining a counter for static variables across classes, but I think thats only because there is a single static variable used in that program.

[WBahn]

This is one of the more subtle -- and clever -- schemes of the VM. But it's pretty easy to see how it all works.

Yes, each class has it's own private static segment, but when you compile Class A to assembly, the variable that it knows as Static 0 gets a name something like A-static-0 while the variable that Class B knows as Static 0 gets a name like B-static-0. Since no two classes in the same Jack program can have the same class name, all of the static variables in all the classes end up with unique names in the assembly language code.

[ivant]

WBahn wrote

This is one of the more subtle -- and clever -- schemes of the VM. But it's pretty easy to see how it all works.

Yes, each class has it's own private static segment, but when you compile Class A to assembly, the variable that it knows as Static 0 gets a name something like A-static-0 while the variable that Class B knows as Static 0 gets a name like B-static-0. Since no two classes in the same Jack program can have the same class name, all of the static variables in all the classes end up with unique names in the assembly language code.

Just a small caveat. The book suggests to use names in the format ClassName.0, ClassName.1, etc. Recently somebody reported a problem with one of the tools breaks with a Java exception if it can't find a dot in the name. So it's better to stick to the suggested notation.

[WBahn]

I agree. I didn't have the book available at the time I responded, so I was speaking in generic terms. But it's definitely worth pointing out the specific recommendation of the book, particularly if the tools have a sensitivity to it. Thanks.

Of course, the tools shouldn't have a sensitivity to it or, if they should, it should be part of the design specification. So it's a bug in the tool that should be fixed. With a new edition of the text coming out, hopefully some effort can be put into patching up the issues with the tool suite that have been discovered over the years.