Hi, Does anyone want to pick this up on the Pharo image side?
I took a brief look at this and while playing I noticed that the errors when we send more than 15 arguments seem a bit strange. Take a look at this snippet: http://ws.stfx.eu/958BXP5GR136 (you can paste it in Spotter to get the playground) In summary: - If we compile a method with a signature containing more than 15 arguments we get: "SyntaxErrorNotification: Too many arguments’”. This is good. - If we compile a method with a message send containing between 16-31 arguments we get: "'InMidstOfFileinNotification’”. Ok-ish. - If we compile a method with a message send containing more than 31 arguments we get: "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to 31’" This is wrong. Did I misunderstand something? Cheers, Doru > On Jun 16, 2016, at 8:10 AM, Clément Bera <[email protected]> wrote: > > 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 ? -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."
