You can see a workaround at http://www.squeaksource.com/Smallapack.html
See package

Smallapack-Compiler.trunk-nice.6.mcz

Le ven. 9 avr. 2021 à 13:28, Stephan Lutz <dev at stlutz.net> a écrit :
>
> 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.
>
>