Traits approaching mainstream Squeak

stéphane ducasse ducasse at iam.unibe.ch
Sat Sep 3 20:45:12 UTC 2005


I discussed with marcus at his birthday party about exupery and this  
is really cool that this is nearly all in Smalltalk.
Keep doing this work.

Stef


On 3 sept. 05, at 20:17, Bryce Kampjes wrote:

> 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