[Vm-dev] Methods with more than 15 args sketch

Clément Bera bera.clement at gmail.com
Thu Jun 16 17:31:09 UTC 2016


On Thu, Jun 16, 2016 at 6:28 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Clément,
>
> On Jun 16, 2016, at 1:21 AM, Clément Bera <bera.clement at gmail.com> wrote:
>
> Yeah I was wondering too, do we pass all arguments in an array or only the
> overflowing arguments ?
>
>
> Definitely only overflowing arguments.
>
>
> 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 ?
>
>
> My analysis is that handling only overflow arguments provides more
> graceful degradation, why?
>
> 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.
>
> 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 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.
>

That second point convinced me.


>
>
> _,,,^..^,,,_ (phone)
>
>
> On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> For my personal use which was essentially calling FFI with more than 15
>> args, i used a single array for all arguments.
>> 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.
>> I don't know if it's the case for other 3rd party code, but it would be
>> worth inquiring...
>>
>>
>> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
>> http://bugs.squeak.org/view.php?id=2918
>>
>> The (Old) Compiler code is at
>>
>> http://www.squeaksource.com/Smallapack.html
>> Smallapack-Compiler.trunk-nice.6.mcz
>> <http://www.squeaksource.com/Smallapack/Smallapack-Compiler.trunk-nice.6.mcz>
>>
>>
>>
>> 2016-06-16 8:10 GMT+02:00 Clément Bera <bera.clement at gmail.com>:
>>
>>>
>>> Hi everyone.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> The generic idea is to change the send calling convention at the
>>> bytecode level, using a temp vector to pass overflowing arguments.
>>>
>>> The normal calling convention in the Smalltalk bytecode is as follows:
>>>
>>> push receiver
>>> push arg 1
>>> push arg 2
>>> ....
>>> push arg N
>>> send selector
>>>
>>> N is limited to 15 arguments due compiled method header & bytecode
>>> encoding.
>>>
>>> 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.
>>>
>>> The convention will look like that:
>>>
>>> push receiver
>>> push arg 1
>>> push arg 2
>>> ....
>>> push arg N
>>> popIntoArray N-15 values
>>> send selector
>>>
>>> The compilation of a method with more than 15 arguments is then changed:
>>> - 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.
>>> - the compiled method header is still marked with 15 arguments
>>>
>>> In addition one needs to change CompiledMethod to:
>>> - allow larger frames (instead of 56 we could allow 128 or 256)
>>> - 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.
>>>
>>> And to change the fall-back of a couple primitives, such as:
>>> - Object>>perform: withArgs:
>>> - Object>>perform: withArgs:inSupedClass:
>>> - BlockClosure>>valueWithArgs:
>>>
>>> This design would allow methods to up to 141 arguments.
>>>
>>> What do you guys think ?
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160616/5928c445/attachment-0001.htm


More information about the Vm-dev mailing list