[Newcompiler] Closure with push and store bytecode

[bryce at kampjes.demon.co.uk]

Mathieu Suen writes:
 > >> The NewCompiler st must be use with RoelTyper  or don't file-in  
 > >> the change for SqueakInstvarInterfaceExtractor.
 > >
 > > I do not get why the NewCOmpiler must be used with RoelTyper?
 > >
 > 
 > Beause RoelTyper Decompile the bytecode to see which message is send  
 > to which InstVar. But RoelTyper don't know about the new bytecode  
 > (ie. push/store Closure Environment)

Be aware that adding bytecodes to the main VM will involve some work
making sure that the changes are OK with other projects. Trying to
work with the bytecodes in the RoelTyper is definitely worthwhile. 1)

I doubt that the current set would be acceptable for the mainstream
VM. I'd like to see a suitable bytecode set developed but I'm not sure
if now is the right time. If you can prove that performance is not a
problem quickly, and you know that making the changes to the bytecodes
later will be cheap then work on more valuable problems now, if not,
I'll try to help.

I'd not put too much work into VM changes. Definitely do change things
to explore and learn. Proving that proper closures can be at least as
fast as the old broken BlockContexts is a major accomplishment. 

At some point, I'd like to see a good set of closure compiler
bytecodes added to the mainstream VM's. The current bytecodes don't
seem ready yet. I'm not sure if now is the right time to develop a
good set of bytecodes.

Marcus: What performance goals does the closure compiler need to meet
now? Or how fast does it need to be before other goals matter more?
And generally how cheap is it to change the bytecode set 2)?  The only
answer that really matters is, is performance a current major issue?

Bryce 

1) I've got an interest here as I'm developing Exupery which tries to
compile bytecode to machine code efficiently. That said, all I need to
know is enough to easily produce fast machine code. That isn't much
different from debugger integration, or other bytecode reading tools.

2) I'm assuming fairly cheap, which is a sign of a very good design,
given how quickly Mathieu added the last bytecode. If changes are
cheap then it's better to defer the decision until later when we'll
all know more.