On 2012-06-21, at 22:32, Nicolas Cellier wrote:

> 2012/6/21 Bert Freudenberg <bert at freudenbergs.de>:
>> 
>> On 2012-06-21, at 19:43, Nicolas Cellier wrote:
>> 
>>> if these are objects rather than literals (that we can expect being
>>> constant), say for example some instance variable, then can we
>>> guaranty that the first message won't have any side effect...
>>> 
>>> (a at: 1) + ( (a at:2) * ( (a at: 1 put: ( ... ) ) + (... ) ) )
>>> 
>>> Nicolas
>> 
>> Did you mean to write we can *not* guarantee it?
>> 
>> I don't think we have to worry about side effects, as long as the evaluation order of all expressions remains the same:
>> 
>>        a := {3. 4}.
>>        (a at: 1) + ( (a at: 2) * (a at: 1 put: 5) ).
>> 
>> is equivalent to
>> 
>>        a := {3. 4}.
>>        t1 := a at: 1.
>>        t2 := a at: 2.
>>        t3 := a at: 1 put: 5.
>>        t4 := t2 * t3.
>>        t5 := t1 + t4.
>>        t5
>> 
> 
> Agree, but then we're back to our initial problem, above code first
> push all parameters then perform all the sends, and might overflow the
> stack limit in-between... We could hack and simulate the stack in such
> case as I proposed , but I feel it will be really teddious to handle
> all of current CompiledMethod limitations...
> 
> Nicolas


No, we have worked around the stack limitation. The expanded form uses temps, not stack slots. And for more temps you had a solution already :)

The first example needs a stack of size 5, while the second one needs only 3. 

The maximum stack depth the expanded form needs is the number of arguments of the message send with the most arguments, plus 1 for the receiver/result.

- Bert -