Closure Compiler

Anthony Hannan ajh18 at cornell.edu
Wed Feb 12 02:02:15 UTC 2003


Daniel Vainsencher <danielv at netvision.net.il> wrote:
> A couple of questions relevant to getting it in the image:
> 1. Do you see us having yet another compiler in the image, coexisting
> with the regular one? If not, what do you propose to do?

Yes, I see us having two compilers until the VM changes to support
faster contexts (Jitter) and possibly some new common send bytecodes
like #createBlock... to reduce compiledMethod size.  BlockClosures will
be slower than BlockContexts until then.  For example, "[(1 to: 100000)
do: [:i | i]] timeToRun" is 50% slower on my machine when [:i | i] is a
closure because it creates a new context each time it is activated
(BlockContexts reuse the same context each time).  Note, this is with
the new closure primitives installed in the VM, without the primitives
it is ridiculously slow.

> 2. Other than that, and needing new VMs, is there anything else that
> needs to change?

For now, only the three new closure primitives need to be added to the
published VMs.  They were previously unused (186, 187, 188) so it won't
hurt adding them.  They are not necessary, but without them closures are
ridicuously slow as stated above.

The only other changes still needed are adapting Etoy tiles to use the
new parse nodes when the closure compiler preference is on, and making
the decompiler more robust.  The decompiler is a pain especially when
trying to handle some bytecode optimizations I added (eliminating
chained and/or jumps, in particular).  I subclassed the existing
decompiler but I would like to rewrite the whole thing, maybe using
SmaCC to create a bytecode parser.  What would this reverse grammar look
like?  Is it reasonable to do?  Or should I stick with the interpreter
pattern?

Scanner and Parser are pretty stable as is and don't really need to be
generated using SmallCC, although it would be nice to use it so we can
have a flexible grammar.  The important thing is the ParseNodes, which
are independent of which parser we use.  I have refactored them so
hopefully they are more useful then the previous ones (the new ones are
subclasses of ParseNode2).

Cheers,
Anthony



More information about the Squeak-dev mailing list