Traits approaching mainstream Squeak

Bryce Kampjes bryce at kampjes.demon.co.uk
Sat Sep 3 18:17:37 UTC 2005


stéphane ducasse writes:
 > 
 > On 3 sept. 05, at 18:08, Bryce Kampjes wrote:
 > 
 > > stéphane ducasse writes:
 > >
 > >> Hi bryce
 > >>
 > >> can you explain to me what is the squeak part of Exupery?
 > >> You have your own compiler? bytecode emitter?
 > >> Did you base it on fullClosure/ RB AST?
 > >>
 > >> Stef
 > >>
 > >
 > > Hi Stef,
 > >
 > > Exupery is a bytecode to native machine code compiler.
 > 
 > I knew that but I thought that the bytecode to native code was done  
 > in C.

Smalltalk is much nicer to write compilers in. ;-)

 > > The compiler itself is written entirely in Squeak. The compiler  
 > > written in Squeak
 > > produces a ByteArray containing generated machine code which is passed
 > > to a primitive to load into a machine code cache. There are a few
 > > modifications to the VM so it will run native compiled methods and a
 > > plug-in which provides the machine code cache.
 > 
 > so this means that you launch the bytetonative for some methods in  
 > the cache
 > at run-time.

Bytecode to native compilation is done by Smalltalk. Smalltalk decides
when and what needs to be compiled. Once it's compiled the method is
loaded into the code cache and registered. I've got a profiler that
will compile the most frequently called methods, the short term
plan is to run this in a background thread.

     Exupery initialiseExupery.
     Exupery
	compileMethod: #add:
	class: OrderedCollection.

First initialises the code cache then compiles OrderedCollection>>add:
and add's it to the native code cache. From then on all calls to
OrderedCollection>>add: will use the native code method.

 > > The goal is to make Squeak much faster, Exupery is only designed to
 > > compile hotspot methods, all other methods will be interpreted.  It's
 > > designed to produce very high quality code at the cost of slow compile
 > > times. It's meant to compile in a background Squeak thread so there
 > > shouldn't be visible compilation pauses.
 > 
 > Ok
 > 
 > > The Squeak part is everything except some run-time support code. The
 > > Squeak code reads a CompiledMethod then translates that into
 > > intermediate code which is optimised, converted into instructions,
 > > register allocated, and assembled producing the the ByteArray
 > > containing machine code.
 > >
 > > So, so long as traits or the fullClosure compiler hasn't changed the
 > > semantics of any bytecodes they should still be compatable with
 > > Exupery.
 > 
 > Normally no bytecode was touches :)
 > 
 > > From memory the fullClosure compiler adds two bytecodes,
 > > Exupery will need to support them to be able to optimise full
 > > closures. But currently Exupery can not compile methods that create
 > > blocks this isn't yet an issue.
 > 
 > Ok I understand better. Do you use the IR representation of the  
 > FullClosure
 > compiler?

I use several different IRs. They are all created especially for
Exupery. The first includes operations such as boxing and deboxing
booleans. This is so I can remove unnessisary boolean conversion code.
Then I use an IR that is a little lower-level than machine code. From
this I form instructions by using simple pattern matching code.

Bryce



More information about the Squeak-dev mailing list