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