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@kampjes.demon.co.uk Reply-To: "Discussion about Exupery a native code compiler."exupery@lists.squeakfoundation.org To: exupery@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@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