Question about behavior's format variable (or MI part 2)
Eliot & Linda
elcm at pacbell.net
Tue Jan 5 03:25:20 UTC 1999
Stefan Matthias Aust wrote:
>
> In the unlikely event of cabin pressure loss...
>
> ...well - I meant, just in case that anybody wants to redo my MI hack, I'd
> like to inform you that I found the problem (after I debugged and corrected
> the InterpreterSimulator for about 40 minutes) and now I can actually have
> more than MapClass-thing providing methods for another MapClass-thing :-)
>
> The line in #isMapClass: must read "(f bitAnd: 16r200000) = 0".
>
> Now, how do I invent a new bytecode for a directed resend instruction?
I think first is a version of perform: that allows one to specify the
starting class. Then get the compiler to generate code that invokes
this better perform:. Note that the debugger can also use this to
execute super sends at full speed. And while you're at it think of
making the doesNotUnderstand: mechanism faster and more informative.
You can make it more informative by making it suplly the class in which
the lookup started, and hence doesNotUnderstand:'s in super sends are
unambiguous. You can make it faster in two ways.
First ensure that the jitter can generate a linked
message-not-understood send. This is easy, simply translate the
doesNotUnderstand method into one with a special prolog does the
doesNotUnderstand processing, and whose selector is the selector of the
message that wasn't understood.
Second, instead of making doesNotUnderstand: cons up a Message object
substitute something like
didNotUnderstand: aSelector startingIn: startClass withArguments:
anArray
You can make it even faster by implementing a var args mechanism so you
don't even have to copy the args from the stack to the argument array.
But that's non-trivial (at least it seems so to me :) ).
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace
More information about the Squeak-dev
mailing list
|