At the moment methods are limited to 15 arguments at most.

Trying to compile a method with more arguments fails:

    with: arg1 with: arg2 with: arg3 with: arg4 with: arg5 with: arg6
    with: arg7 with: arg8 with: arg9 with: arg10 with: arg11 with: arg12
    with: arg13 with: arg14 with: arg15 with:  "Too many arguments ->"arg16

         ^ 42

This limitation is enforced in Encoder >> bindArg:

    bindArg: name
         "Declare an argument."
         | node |
         nTemps >= 15
             ifTrue: [^self notify: 'Too many arguments'].
         node := self bindTemp: name.
         ^ node nowHasDef nowHasRef

Looking at where this limitation comes from, I noticed that a method 
header only has 4 bits reserved for the number of arguments:

    header
         "Answer the word containing the information about the form of the
          receiver and the form of the context needed to run the receiver.

             sign:1 29-28:accessModifier 27-24:numArgs 23-18:numTemps
    17:largeFrameFlag 16:hasPrimitive 15:isOptimized 14-0:numLits"

         ^self objectAt: 1

This, however, only uses 32 bits in total. In a 64bit image, the other 
32 bits seem to be unused.

Question: Is the limit of 15 arguments still accurate on modern VMs & 
bytecode sets?

Stephan


Disclaimer: No, I do not want to pass every single pixel of my bitmap as 
an argument ^^. But apparently other people's C-style libraries do, and 
I need to interface with one through FFI. Yes, I could build and invoke 
ExternalFunctions manually, but I would reeeaaally prefer not to if 
given a choice.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210409/43b70616/attachment.html>