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