<div dir="ltr"><div>Hi Eliot,</div><div><br></div><div>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.</div>
<div><br></div><div>2013/8/15 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div dir="ltr">Hi Clément,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 5:28 AM, Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div dir="ltr">
Hello Eliot and all,<div><br></div><div>Recently I watched a video of Eliot introducing Cog (<a href="http://www.youtube.com/watch?v=-ei1bnLHdhA" target="_blank">http://www.youtube.com/watch?v=-ei1bnLHdhA</a> part 1 to 7).</div>
<div><br></div><div>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). </div></div>
</blockquote><div><br></div><div>This is actually the production JIT. It is called StackToRegisterMappingCogit. It performs the following optimizations:</div><div><br></div><div>- 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).</div>
<div><br></div><div>- 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]).</div></div></div></div></blockquote><div><br></div>
<div>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 ? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>- 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.</div>
</div></div></div></blockquote><div><br></div><div>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 ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div> - 0 and 1 argument sends assign their receiver and argument to registers, avoiding the stack altogether</div><div> - 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</div>
<div> - inst var stores can avoid a store check if the value assigned is a SmallInteger literal</div><div> - 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)</div>
<div> - some dead code is eliminated (e.g. all code following true ifTrue: [^1]. is removed)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>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.</div>
<div><br></div><div>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 ? </div>
<div><br></div><div>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 ?</div>
</div></blockquote><div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div>Thanks for any answers,<br></div><div><br></div><div>Clement</div></div></blockquote></div><div class="gmail_extra"><br></div>Others have referenced dynamic deoptimization. +1.<br>-- <br>best,<div>Eliot</div>
</div></div>
<br></blockquote></div><br></div></div>