I reworked how the compiler deals with local variables. Now all local variables (as well as parameters) are included in the fcode definition of a method. This should provide the info required by the .NET emit process, and will provide a place for me to mark variables as "used-by-ref" so that I can wrap them for Java emit. I didn't have my original data structures right, so it was kind of a pain the ass. The new fcode format:
method
{
u2 name (names.def)
u4 flags
u2 returnType (typeRefs.def)
u1 paramCount
u1 localCount
methodVar[paramCount+localCount] vars
buf code
u2 facetCount
facet[facetCount] facets
}
methodVar
{
u2 name (names.def)
u2 type (typeRefs.def)
u1 flags
buf defaultExpr
}
I also took the opportunity to refactor how scoping works to fix a few problems. Before, reusing a variable name in different blocks (like a for loop) didn't work - it treated the whole method body like one block scope. It should work now.
Currently every local variable is given it's own register number, regardless of block scope. This makes life simple, because in Java you aren't allowed to reuse a register with two different types. However I notice that javac coalesces locals with the same type in different blocks into the same register as an optimization. That might be something we ought to do too, although I'd like to understand more how the CLR deals with locals first.
brian Thu 9 Feb 2006
I reworked how the compiler deals with local variables. Now all local variables (as well as parameters) are included in the fcode definition of a method. This should provide the info required by the .NET emit process, and will provide a place for me to mark variables as "used-by-ref" so that I can wrap them for Java emit. I didn't have my original data structures right, so it was kind of a pain the ass. The new fcode format:
method { u2 name (names.def) u4 flags u2 returnType (typeRefs.def) u1 paramCount u1 localCount methodVar[paramCount+localCount] vars buf code u2 facetCount facet[facetCount] facets } methodVar { u2 name (names.def) u2 type (typeRefs.def) u1 flags buf defaultExpr }I also took the opportunity to refactor how scoping works to fix a few problems. Before, reusing a variable name in different blocks (like a for loop) didn't work - it treated the whole method body like one block scope. It should work now.
Currently every local variable is given it's own register number, regardless of block scope. This makes life simple, because in Java you aren't allowed to reuse a register with two different types. However I notice that javac coalesces locals with the same type in different blocks into the same register as an optimization. That might be something we ought to do too, although I'd like to understand more how the CLR deals with locals first.