[ANN] Exupery, yet another compiler project

Bryce Kampjes bryce at kampjes.demon.co.uk
Fri Mar 28 17:07:19 UTC 2003


Daniel Vainsencher writes:
 > Ooh, cool. I assume it targets x86?

Currently I only target x86 on Linux. It shouldn't be hard to extend
both to other operating systems and also to other CPUs.

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

Compiling to assembly it can handle an iterative factorial. Compiling
inside the image is still very limited because of the assembler. That
is my current project.

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

I'm compiling regular Smalltalk CompiledMethods down to machine code
then running that. Ideally, it should use polymorphic inline caches
and adaptive recompilation with type feedback to produce really fast
code, probably about half the speed of C but that would take a least a
years work full time without distractions. By just targeting inner
loop methods now I hope to be able to produce something useful much
quicker. Then I can build it up slowly supporting more byte codes and
more optimization's.

Once the assembler can handle compiling an iterative factorial the
next step will be message sends. They are required for the integer
byte codes anyway, overflows are handled by sending and so is
non-SmallInteger arithmetic.


There is still a big difference between handling sends at all and
handling them efficiently. The best optimization for sends is to inline
them away. I don't want to start trying to speed up sends until after
I've got useful byte code speed ups.


It might be better to think of it as three projects. The first one is
as small as possible to be easily achievable, compiling individual
methods to speed up bytecode performance. The second one is larger and
should be easily achievable on top of the first, a useful general
purpose dynamic compiler for Squeak. The third is a lot of dreams
about what computers could be and involves redrawing the abstraction
boundaries in systems software. I'm currently focusing on the first
which is why I'm interested in easy uses for the compiler now.

Thanks for your interest
Bryce



More information about the Squeak-dev mailing list