[Vm-dev] Register allocation and debugging in Squeak

[Clément Bera]

Hi Eliot,

I may be interested to discuss about that on a Skype. However I've just
taken my summer vacation and then I will be very busy with ESUG. So I will
contact you back mid September (after ESUG). I will have time then to work
on different things.

2013/8/15 Eliot Miranda <eliot.miranda at gmail.com>

>
> Hi Clément,
>
>
> On Tue, Aug 13, 2013 at 5:28 AM, Clément Bera <bera.clement at gmail.com>wrote:
>
>>
>> Hello Eliot and all,
>>
>> Recently I watched a video of Eliot introducing Cog (
>> http://www.youtube.com/watch?v=-ei1bnLHdhA part 1 to 7).
>>
>> At some point, Eliot says that a better code generator was planned with
>> optimizations such as constant folding and stack to register mapping (I
>> guess it does exist, but as a prototype only).
>>
>
> This is actually the production JIT.  It is called
> StackToRegisterMappingCogit.  It performs the following optimizations:
>
> - 0 and 1 argument methods pass their receiver and argument in registers;
> Those 0 and 1 argument primitives that the JIT compiles access their
> arguments from registers (e.g. at: and SmallInteger and Float arithmetic).
>
> - certain methods when compiled don't build a frame, e.g. Point>>setX:Y:
> (this is new as of this week :-), [:arg| arg], [:a! :a2| a1 == a2]).
>

In some way, not building a frame is like inlining, isn't it ? So basically
you don't build a frame for methods that has no message sent and no back
jump ?

>
> - code is not generated until bytecodes that consume operands are
> encountered (this is the major optimization).  During compilation operands
> are pushed onto a simulation stack, and bytecodes that consume operands can
> then analyse their operands when generating code, in many cases avoiding
> pushing their operands onto the stack.  e.g.
>

This means that if you have a condition but the the code always go into the
same branch then the branch not called will never be generated ?


>      - 0 and 1 argument sends assign their receiver and argument to
> registers, avoiding the stack altogether
>     - special selector arithmetic and comparison can avoid detagging
> literal integer operands, and avoid reifying the results of comparison
> operations to true and false if followed by a conditional branch bytecode
>     - inst var stores can avoid a store check if the value assigned is a
> SmallInteger literal
>     - arithmetic constant-folding is done provided that the expression
> starts with a literal (e.g. the Cogit will collapse 1 + 2 + var to 3 + var,
> but won't collapse var + 1 + 2 to var + 3)
>     - some dead code is eliminated (e.g. all code following true ifTrue:
> [^1]. is removed)
>
>
> However, it seems that this last optimization (register allocation) is
>> tricky to manage with the debugger: in the Self VM, it seems that the
>> contexts were in read-only in the debugger because they didn't know if the
>> variable was stored in a register or in the memory.
>>
>> Now I know that Eliot wouldn't have planned an optimization that will
>> destroy the debugging power of Squeak. How did you guys plan to add the
>> register allocation without destroying the debugging power of Squeak ?
>>
>> Did you plan to add something similar to the scope descriptor that they
>> have in the Self VM to allow aggressive optimizations with regular
>> debugging ? Did you plan to annotate the stack frames with meta data and if
>> so, how would you have implemented it ?
>>
>
> Clément, I have plans (and God is doubtless amused) but nothing in
> progress.  If you're interested on doing work here then let me know and
> perhaps we could skype sometime soon to discuss?
>
>  Thanks for any answers,
>>
>> Clement
>>
>
> Others have referenced dynamic deoptimization.  +1.
> --
> best,
> Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130815/db932cd0/attachment.htm