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
>  
>
Are the IRs described anywhere (url) other than in the code? 

Also, would other ports just use a different pattern-matcher in that 
last step?  (i.e. is the low-level IR general enough to allow other 
architectures of machines?) 

David