Colin Putney writes:
 > 
 > Yes, "Parse trees are structured CompiledMethods". I'd love to see 
 > Squeak executing ASTs with the hotspots optimized by Exupery.

I do like the idea, and Exupery is progressing slowly towards
being useable. In fact, my current efforts are aimed solely at
making Exupery useful for hot leaf methods. It's easier to make
a compiler perform for leaf methods than for sends. Sends are
next, after tolerably good leaf method performance. But...

An AOStA style approach with two levels of byte-code could make
a lot of sense. The first bytecode is highlevel, the flattened
AST, basically Squeak bytecode without jumps so no inlining of
conditional (ifTrue:ifFalse: etc) and loop control flow methods.
With a second low level bytecode that's closer to Squeaks current
full byte-code, with maybe a type check bytecode to make inlining
fast, to inline down to all done at the Smalltalk above bytecode
level could provide a workable fast execution engine for what, I
think, you are describing.

The double bytecode inlining interpreter would, probably, be faster
for normal code than our current engine. Sends are very expensive so
removing them should provide a decent speed improvement. It's a
design, as Marcus suggested, that is very much in the AOStA spirit,
with both a high level bytecode and a low level bytecode. 

Of course it would be nice to use a compiler that went all the way
down to machine code but it's always best to know that you can succeed
without relying on other projects meeting their milestones. A backup
plan doesn't need to be executed, it just needs to reduce the total
risk. Once everything is done and working together there is no risk
left.

How is AOStA going? Is there a decent bytecode level inliner that
could be borrowed for other projects? 

Bryce
Who does hope, and is working to make, Exupery ready before it
is needed for your work.