[squeak-dev] Compiler

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Jun 21 20:32:12 UTC 2012


2012/6/21 Bert Freudenberg <bert at freudenbergs.de>:
>
> On 2012-06-21, at 19:43, Nicolas Cellier wrote:
>
>> 2012/6/21 Bert Freudenberg <bert at freudenbergs.de>:
>>>
>>>        ^ 1 + (2 + (3 + 4))
>>>
>>> is exactly equivalent (same order of message sends) to
>>>
>>>        | t1 t2 |
>>>        t1 := 3 + 4.
>>>        t2 := 2 + t1.
>>>        ^ 1 + t2
>>>
>>> If the temp number limit was lifted this would be the way to go, I think.
>>>
>>> - Bert -
>>>
>>
>> Sure, it's rather theorical without thinking of any application, but
>> 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

>
> - Bert -
>
>
>


More information about the Squeak-dev mailing list