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

[Clément Bera]

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