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

[Nicolas Cellier]

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/76f0e987/attachment.htm