<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 18, 2017 at 9:04 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi Bert, Hi All,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 10:55 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 18, 2017 at 6:09 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Concerning the specific case of hashMultiply, since it's just an imul and a bitAnd, the primitive should be inlined by the VM just like other basic arithmetic operations IMO.<br></div><div>So the remarks of Andres makes sense, even if we can't generalize to other Misc primitives.<br></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">Yes, code optimized by Sista should be pretty much as fast as a primitive, so we could hopefully get rid of many primitives that are just there to improve performance.</div></div></blockquote><div><br></div><div>The problem to think through carefully is the impact on the ContextInterpreter, StackInterpreter and SqueakJS VMs.  I have a gut feeling that the right thing to do is to keep the primitives for the benefit of these VMs and to have Cog ignore them. </div></div></div></div></blockquote><div><br></div><div>Ah, good point.</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> That implies that the primitive failure code can be what one would like to execute and have Sista optimize.  That means that translated primitives are an obstacle.</div></div></div></div></blockquote><div><br></div><div>Agreed. </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>Rewriting the translated primitives as conventional primitives in MiscPrimitivePlugin and not including the MiscPrimitivePlugin in Cog (JIT) VMs (o including one which provides no primitives) would allow the primitive failure code in the various Collection methods to be written optimally, allow the interpreter VMs to keep using the primitives, allow Cog VMs to ignore the primitives easily, and would allow putting the primitives closer to the receivers.  Redirecting through to the class side wastes cycles.</div></div></div></div></blockquote><div><br></div><div>Yep :)</div><div><br></div><div><div>- Bert -</div> </div></div></div></div>