Ooh, cool. I assume it targets x86?

For a first step - do you have the obligatory 3 + 4 working?

Is this intended as a subset-of-smalltalk-for-primitives, or as a
full-smalltalk-to-machine code kind of compiler? IOW, will it support
sends?

I ask because on the one hand you say it will compile regular Smalltalk,
and OTOH you say it's for inner loops.

Daniel

Bryce Kampjes <bryce at kampjes.demon.co.uk> wrote:
> 
> This is the first public release of Exupery, my byte code compiler,
> for Squeak. It doesn't yet do much but it is a documented example of
> test driven code.
> 
> The first useful goal is to compile inner loop methods. Hopefully it
> should be able to provide an alternative to Slang for some inner loop
> methods. The idea is to compile normal methods to machine code. This
> should provide a tolerable speed up with much less effort than Slang
> and hopefully get the compiler into real use early.
> 
> What would be the smallest subset of Squeak byte codes needed to be
> useful for just one project? Or which methods would it be worth while
> compiling first?
> 
> Exupery is available on SqueakMap and there is some documentation at
> http://www.kampjes.demon.co.uk/. Feedback on both the code and the the
> documentation is very much appreciated.
> 
> The compiler can compile a single method inside the image and run
> it. It is currently limited by the assembler. The system can produce
> tolerable code and includes a coloring register allocator. It's an
> architectural skeleton that is fully end to end.
> 
> The project dream is to soften the barrier between language
> implementation and normal development. It would be nice if playing
> around with a dynamic compiler was no more risky than modifying the
> collections classes. Also there are a large number of other projects
> that could use dynamic code generation.  The idea of live code
> generation is not new but hasn't been widely used. For instance,
> compiling regular expressions and LR grammars to machine code could
> make a Squeak implementation faster than in C if only we could do
> this without needing extremely hairy programming.
> 
> Bryce