Traits approaching mainstream Squeak
ducasse at iam.unibe.ch
Sat Sep 3 17:22:16 UTC 2005
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?
> 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
> 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 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.
> 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
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
More information about the Squeak-dev