RE: Porting

Hi David,

David Griswold writes:
 > If all that happens is that whenever a typecheck fails you jump
 > to a single alternate flow of control that does only sends and avoids
 > all inlining, then that sounds like the equivalent of an uncommon trap,
 > except that you lose the biggest advantage of deoptimization, which is
 > that compilation and inlining are completely transparent to the debugger
 > and all other kinds of context reflection.
 >
 > How does Exupery compiled code work with the debugger (especially when you
 > start doing inlining)?  How would the reflection that for example Seaside
 > does, work with
 > compiled contexts?

Exupery can decompile a context at any time, it's just done in the
image by using reflection. Contexts are just normal objects in Squeak
and Exupery adds it's own context classes. Exupery's contexts are
responsible for converting themselves into interpreted contexts when
necessary. (1)

If anything is done to an Exupery context that could invalidate the
assumptions of compiled code then the context should convert itself to
an interpreted context. So if the debugger trys to change a context it
should convert itself back to an interpreted context. The profiler
however should not cause contexts to convert themselves to interpreted
contexts.

It's the ExuperyContext's responsibility to convert itself into an
interpreted context when Seaside serializes it. Seaside could
serializes an ExuperyContext but that could cause a crash if the
ExuperyContext converted itself into an interpreted context then
Seaside recreated the stack with it in. ExuperyContexts have different
instance variables to interpreted contexts so filling an interpreted
contexts variables using instVarAt:put: after taking them from an
Exupery context with instVarAt: is dangerous. If Seaside calls a
context to save itself rather than using instVarAt: to get the state
out then making it work with Exupery is easy. An Exupery context could
also convert itself if instVarAt: is called on it.

ExuperyBlockContext>>convertToInterpretedContext will convert an
Exupery block into an interpreted block. It re-arranges the instance
variables then calls primitiveChangeClassTo: to change the class.

Exupery manages it's code cache purely in the image. It needs to
convert all Exupery contexts back to interpreted contexts before
flushing the code cache or saving the image. Otherwise it may try
to execute compiled code that's not there.

Uncommon traps are definitely a very nice optimization for a fast
compiling compiler. By removing the need to produce the code they
speed up compilation. However uncommon traps do make it harder for a
slow compiler that trys to produce very fast code.

 > Strongtalk doesn't do any of that right now.  The normal uncommon trap
 > mechanism, combined with our use of 0 tags for SmallIntegers, means that
 > SmallInteger arithmetic is very fast already, since addition for example
 > doesn't require any tag manipulation at all, so we don't really have to
 > worry about conversion/deconversion issues.

I was thinking about true 32 bit integers not SmallIntegers. True 32
bit integers are needed for a few applications such as cryptology. The
Squeak cryptography guys are currently writing a few primitives to
speed up their inner loops.

 > As for double precision floats, they could be done the way you are
 > suggesting, which would be nice, but right now they are not done that way.
 > Right now our "fast float" experiment uses special bytecodes that treat them
 > as a non-OO basic type (with explicit conversion to and from objects).  But
 > that was just a quick experiment that Robert Griesemer did, and it is not
 > really part of the "language", although they work and are very fast.

Sounds interesting, I'd like to talk more about it when I'm ready to
start work on floating point.

Bryce

(1) The description is true for block contexts but not method
contexts. Exupery method contexts currently share the same class as
interpreted method contexts. I'll create their own class before 1.0.
Before blocks the old style Exupery method contexts were executable by
a normal VM which was very nice for early bootstrapping. This also
meant that the debugger would work for them unless it was single
stepped.

The decompilation code is present and well tested. What's missing is
the hooks to trigger decompilation when a context is manipulated via
reflection.
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery