Smalltalk › Squeak › Other › Squeak - Exupery

Exupery and the Closure Compiler

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Bryce Kampjes

Exupery and the Closure Compiler

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

J J-6

RE: Exupery and the Closure Compiler

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: <[hidden email]>
>Reply-To: "Discussion about Exupery a native code
>compiler."<[hidden email]>
>To: [hidden email]
>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
>[hidden email]
>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

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery