On Fri, May 24, 2002 at 03:59:46PM -0700, Tim Rowledge wrote:
> > Why isn't it getting use?
> I honestly couldn't give a decent answer to that. Probably words like
> 'freetime', 'opportunity' and 'laziness' would creep into answer from
> most of us!
>
yes. Laziness. 
 
> Err, you've got me there. I suppose you could actually do some sort of
> sned-site cache in the compiled methods; hmm it would cost you a word
> associated with each send, which probably adds up a bit but never mind,
> some case would be painful (I'm thinking special bytecode sends), mostly
> I have a feeling it wouldn't make much diference over the global lookup
> cache without the system also having faster send protocols  -  a lot
> of saving and restoring goes on in a simpel interpreter which must
> surely swamp a relatively trivial lookup). I wonder if it might play
> nicely with the different context stack stuff Anthony H did for the
> block closures stuff? 
> 
> 
I was thinking if it would possible to look at the Interpreter as "just
another instructionset" for a Jitter. Then the Jit could do the same
optimisations for the Bytecode that it does for native code, and thus
it might be possible to simplify the bytecode saved in the CompiledMethods.

Today the "code" for Scripting (etoys and omniuser) is generated by
decompiling bytecodes. Maybe it would be worth to look into generalising
this: Throw away the source, and save some kind of AST-representation of
the method. Then everything could be generated on-the-fly: Tiles, Source,
Bytecode (for the Interp) or Machinecode. 
This would allow to "late bind" the syntax used, and even the bytecode-set
of the VM. 
I really don't know if this could be made to run fast enough...

     Marcus

-- 
Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeakland.org