Exupery and the Closure Compiler

[J J]

IMO, the only reason we don't use the closure compiler (i.e. have real 
closures and not worry about low level details like #clone and #fixTemps) is 
speed.  Since Exupery is about speeding things up, that is exactly the 
compiler I would target with it.

My hope for Exupery is that since it is able to speed things up, many hacks 
required today can be taken out, and the broken closure implementation is 
high on that list.


>From: <bryce at kampjes.demon.co.uk>
>Reply-To: "Discussion about Exupery a native code 
>compiler."<exupery at lists.squeakfoundation.org>
>To: exupery at lists.squeakfoundation.org
>Subject: Exupery and the Closure Compiler
>Date: Fri, 27 Apr 2007 22:22:02 +0100
>
>
>Should Exupery 0.12 be made compatible with the closure compiler? Both
>Exupery and the closure compiler use the "unused" slot in
>MethodContext. Exupery uses the slot to indicate that the
>MethodContext uses native code. The closure compiler uses it to hold a
>pointer to the environment which contains shared variables.
>
>Exupery uses it because until recently Exupery used to use normal
>MethodContexts when executing compiled code. The native program
>counter was stored in the "unused" slot. If the slot was a
>SmallInteger it was the address to jump to to resume native code, if
>it was a nil then the context should be interpreted.
>
>When I added block support I moved the native program counter into the
>same slot as the interpreted program counter. Later
>ExuperyMethodContext was created to allow the debugger to work with
>compiled method contexts again. Originally they were the same to the
>debugger, but the "unused" slot should have been nilled out if the
>context was single stepped. With the native PC in the PC slot having a
>dedicated context object makes it easier to work with
>tools. Polymorphism can deal with converting the native program
>counter into a bytecode program counter and decompiling a context
>if it's changed through reflection.
>
>It's probably worthwhile me having a proper look at the logic to
>switch between native code and interpreted code. There was a bug
>that's been fixed in the Slang support (going from interpreted to
>compiled) and I'm not sure that the native code check has the same bug
>(going from compiled to interpreted). The bug was that interpreted
>blocks with a SmallInteger receiver were being treated as native code.
>
>I guess I should investigate before 0.12 even if I then decide not
>to change it.
>
>Are people interested in running Exupery and the closure compiler
>at the same time?
>
>Bryce
>_______________________________________________
>Exupery mailing list
>Exupery at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

_________________________________________________________________
MSN is giving away a trip to Vegas to see Elton John.  Enter to win today. 
http://msnconcertcontest.com?icid-nceltontagline