<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 6:28 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="auto"><div>Hi Clément,<br></div><div><br>On Jun 16, 2016, at 1:21 AM, Clément Bera <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr">Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ?</div></div></blockquote><div><br></div>Definitely only overflowing arguments.<div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ?</div></div></div></blockquote><div><br></div>My analysis is that handling only overflow arguments provides more graceful degradation, why?</div><div><br></div><div>When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly.</div><div><br></div><div>But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a <span style="background-color:rgba(255,255,255,0)">1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method.</span></div></div></blockquote><div><br></div><div>That second point convinced me.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><br></div><span style="background-color:rgba(255,255,255,0)"><br>_,,,^..^,,,_ (phone)</span><div><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@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"><div><div>For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.<br></div>This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.<br></div>I don't know if it's the case for other 3rd party code, but it would be worth inquiring...<br><div><div><br><a href="https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak" target="_blank">https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak</a><br><a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html</a><br><a href="http://bugs.squeak.org/view.php?id=2918" target="_blank">http://bugs.squeak.org/view.php?id=2918</a><br><br></div><div>The (Old) Compiler code is at <br><br><a href="http://www.squeaksource.com/Smallapack.html" target="_blank">http://www.squeaksource.com/Smallapack.html</a><br><a href="http://www.squeaksource.com/Smallapack/Smallapack-Compiler.trunk-nice.6.mcz" target="_blank">Smallapack-Compiler.trunk-nice.6.mcz</a><br><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-16 8:10 GMT+02:00 Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi everyone.<div><br></div><div><div style="font-size:12.8px">It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The normal calling convention in the Smalltalk bytecode is as follows:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">push receiver</div><div style="font-size:12.8px">push arg 1 </div><div style="font-size:12.8px">push arg 2 </div><div style="font-size:12.8px">....</div><div style="font-size:12.8px">push arg N</div><div style="font-size:12.8px">send selector</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">N is limited to 15 arguments due compiled method header & bytecode encoding. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The convention will look like that:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div>push receiver</div><div>push arg 1 </div><div>push arg 2 </div><div>....</div><div>push arg N</div><div>popIntoArray N-15 values</div><div>send selector</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The compilation of a method with more than 15 arguments is then changed:</div><div style="font-size:12.8px">- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.</div><div style="font-size:12.8px">- the compiled method header is still marked with 15 arguments</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In addition one needs to change CompiledMethod to:</div><div style="font-size:12.8px">- allow larger frames (instead of 56 we could allow 128 or 256)</div><div style="font-size:12.8px">- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">And to change the fall-back of a couple primitives, such as:</div><div style="font-size:12.8px">- Object>><span style="font-size:12.8px">perform: withArgs:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">- Object>></span><span style="font-size:12.8px">perform: withArgs:inSupedClass:</span><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px">- BlockClosure>>valueWithArgs:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">This design would allow methods to up to 141 arguments.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">What do you guys think ? </div><div>
</div></div></div>
<br></blockquote></div><br></div>
<br></blockquote></div><br></div></div></div></div></div>
</div></blockquote></div></div></div><br></blockquote></div><br></div></div>