[Vm-dev] Register allocation and debugging in Squeak
bera.clement at gmail.com
Thu Aug 15 08:01:40 UTC 2013
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
> - 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,
> Others have referenced dynamic deoptimization. +1.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev