On Wed, 13 Sep 2006 21:26:13 +0200, Bryce Kampjes wrote:
> Klaus D. Witzel writes:
>  > Hi Bryce,
...
>  > I can imagine that Exupery encounters similar situations (i.e. native  
> code
>  > does a full send for whatever reason). Is there something that can be
>  > learned (or, perhaps, even copied) from Exupery.
>
> Exupery modifies commonReturn: and transferTo: amongst other methods
> to allow it's modified contexts to be re-entered from compiled code.

Yes, that's what I thought.

> I suspect that implementing #apply:from:to:on: in Squeak is a mistake.

A possible performance improvement by a factor of 3 is not what people  
would count a mistake.

> First because it'll make the code less clear.

"old" start to: stop do: [:index | aBlock value: (self at: index)]
"new" self applyTo: aBlock from: start to: stop

differences are: method name, receiver and arguments swapped.

no difference: self is typed, aBlock is typed by convention.

> Second because it's
> going to be very hard to do with the current VM and contexts,

Yes, certainly. I'd therefore attempt to have a context to which the  
activation can return. 4 LOC in #commonSend, 6 LOC in #commonReturn (not  
counting comments).

> VisualAge doesn't have context objects which would make this sort of
> thing easier but also means that it can't support Seaside.

Yes, that's what danil conjectured. Can't say much about VA St.

> Third
> because I'd need to re-implement any such primitive in Exupery.

Since Exupery either compiles or interprets, I'd suggest that it ignores  
the <primitive: 164> header mark (number is fake here) and just compiles  
the shadow (same as below).

> Forth
> because you'll need to implement the primitive in the debugger so you
> can still single step through do:.

Let noughty stack manipulator just ignore (primitive = 164) and step  
through the shadow (even on return from some activation).

> Fifth because such a primitive will
> be harder to understand than our current do: implementation.

It is a Stream>>#next followed by a BlockContext>>#value: (with some type  
checks mixed in). All that can be "reused" from the respective existing  
primitives in the VM. But those who don't understand Stream>>#next and  
BlockContext>>#value: would have a hard time ;-)

> And
> finally because the current implementation or even one using count:
> could be fully optimised by using full method inlining and a decent
> optimising compiler.

Same would be the case with #applyTo:from:to:, what could be a possible  
difference when comparing the above snippets.

> Full method inlining will optimise much more than
> just do: and friends.

Absolutely. Just ignore cases with (primitive = 164) and do a full inline  
of the respective shadow.

/Klaus

> Full method inlining would also allow us to stop inlining methods such
> as ifNotNil: without any drop in speed. Either optimise a very general
> case or optimise a specific case based on profiling.
>
> Bryce
>
>