Hi Bryce,

turning the suggested primitive behind BlockContext>>#apply:from:to: into  
a #primitiveValue is, after checking receiver and arguments, easy.

Problems come as soon as the block later sends, whereafter #commonReturn  
does no longer know anything about #primitiveApplyFromTo. This asks for  
something that stores such state, for example by making a  
MethodContext>>#apply:from:to:on: solution (with last argument the block).

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.

/Klaus

On Tue, 12 Sep 2006 21:07:12 +0200, Bryce Kampjes wrote:

> Klaus D. Witzel writes:
>
>  > But I think this is something for a 1.0 Exupery release; if I  
> understand
>  > Bryce correctly he aims to outperform a certain commercial VM and
>  > MethodContext>>#apply:from:to: looks like it's worth the effort (of
>  > course, with fall back to good old #do: code-in case the new  
> primitive is
>  > missing). My CHF 0.05.
>
> The right way to optimise occurrencesOf: is to write it using count:
> then to inline away the overhead of using #do: by using an inlining
> JIT as Nicolas suggested. My aim is to add inlining to Exupery in 2.0.
>
> The goal of 1.0 is to provide a useful speed improvement to
> Squeak. That involves making Exupery more reliable and implementing
> key primitives. Unfortunately, many inner loops in Squeak spend most
> of their time calling primitives so improve their performance I need
> to reimplement the primitives. Exupery has been faster than
> VisualWorks for the bytecode benchmark for over a year now.
>
> I could have also said that the goal for Exupery 1.0 is to provide
> everything necessary to benefit from method lining except for method
> inlining. Exupery can inline primitives already.
>
> Bryce
>
>
>