[Newcompiler] TODO list NewCompiler

[Mathieu Suen]

Sorry now I see what you mean but I don't understand something:

You mean that in non closure mode we can't use pushInstVar bytecode. Tthere is no way to generate it?

----- Message d'origine ----
De : Marcus Denker <denker at iam.unibe.ch>
À : "The New Compiler, AST, IRBuilder, Closures..." <newcompiler at lists.squeakfoundation.org>
Envoyé le : Mercredi, 2 Août 2006, 10h19mn 20s
Objet : Re: [Newcompiler] TODO list NewCompiler


On 27.07.2006, at 10:16, Stéphane Ducasse wrote:

>
> what is the diff between a field and an instVar access?

The IRBuilder adds the concept of accessing instVars of objects
other then "self" directly. This is needed for accessing variables
in blocks: e.g. temp Variables in Blocks are not shared with the
method's context, but they live in an "environment" that is independed
of the method context. The bytecode generated now need to access
these variables in the environment object.

For making everything uniform, Anthony decided to just have the concept
of "field access" in IRBuilder, where you push the object whose iVar you
want to access first, then do a pushField: or popField.

If the object is "self", this gets compiled to be a normal push/pop  
InstVar,
when it's another object, it uses messages to access the instVar, as  
there
are no bytecode to to it directly.

When I did the "non Closure" mode for the NewCompiler, I renamed all the
Field related stuff to be "InstVar"... this was a good decicion for  
non-closure
mode and bytesurgeon, but when we want to do both, we need to think a  
bit
harder.

Right now it is impossible to write IRBuilder code that works in both  
closure/
non-closure setting, as when in closure mode we need to do a
    pushSelf;
    pushInstVar: 1

and in non-closure mode it's
    pushInstVar: 1

This needs to be fixed. One idea would be to have *both* the concept of
"Field" and "iVar", so people can use iVar when do non-closure stuff. Or
onother option would be to go back to  have the 'Field' concept only...


     Marcus