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

Clément Bera bera.clement at gmail.com
Thu Jun 16 08:21:00 UTC 2016


Yeah I was wondering too, do we pass all arguments in an array or only the
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 ?



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/03d98a41/attachment-0001.htm


More information about the Vm-dev mailing list