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.

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

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

Stef
>
> Bryce
>
>
>