> That's an interesting position given his work on the AOStA bytecode
> optimizer. My guess would be that the more you optimize the bytecodes,
> the less they look like the parse tree that created them.
>
>
Yes, but that would be totaly transparent for the user (e.g. the
developer). A dynamic optimizing system always de-optimizes as soon
as you try to look harder (e.g with the debugger).

So all the magic of AOStA is pretty much invisible. On the other hand:
Having a Jitter around by default means that we don't care
about how bad the non-optimized code is wrt. to execution. We could use
the AST directly. (Or better, a compressed version like
franz' Slim Binaries...).

So "CompiledMethods are flattened parsetrees" does not mean that you
would use the cm we have now as the AST, but use the
AST as the compiled methods...

      Marcus

 > 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.

Bryce