Methods with more than 15 arguments?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Methods with more than 15 arguments?

stlutz

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.



Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

Nicolas Cellier
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 <[hidden email]> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

Nicolas Cellier
Note that Smallapack passes all arguments into a single array.
Eliot Miranda suggested to pass first 14 arguments as usual, and only
the last+excess arguments into an array, but nobody did work on such
implementation. I do not remember pros and cons either, need to
various scan mailing lists (squeak or vm-dev ?)...

Le ven. 9 avr. 2021 à 16:01, Nicolas Cellier
<[hidden email]> a écrit :

>
> 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 <[hidden email]> 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.
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

codefrau
Yep, that’s how it should work (array as 15th arg). I guess it would be relatively simple to make the encoder do that. 

Vanessa

On Fri, Apr 9, 2021 at 07:14 Nicolas Cellier <[hidden email]> wrote:
Note that Smallapack passes all arguments into a single array.
Eliot Miranda suggested to pass first 14 arguments as usual, and only
the last+excess arguments into an array, but nobody did work on such
implementation. I do not remember pros and cons either, need to
various scan mailing lists (squeak or vm-dev ?)...

Le ven. 9 avr. 2021 à 16:01, Nicolas Cellier
<[hidden email]> a écrit :
>
> 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 <[hidden email]> 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.
> >
> >



Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

codefrau
... and the FFI compiler could then compile that into a proper external function call. Which is probably better than trying to make the FFI plugin understand the 14+array convention, but I might be mistaken. 

Incidentally, which library/function specifically do you want to call? 

Vanessa


On Fri, Apr 9, 2021 at 09:43 Vanessa Freudenberg <[hidden email]> wrote:
Yep, that’s how it should work (array as 15th arg). I guess it would be relatively simple to make the encoder do that. 

Vanessa

On Fri, Apr 9, 2021 at 07:14 Nicolas Cellier <[hidden email]> wrote:
Note that Smallapack passes all arguments into a single array.
Eliot Miranda suggested to pass first 14 arguments as usual, and only
the last+excess arguments into an array, but nobody did work on such
implementation. I do not remember pros and cons either, need to
various scan mailing lists (squeak or vm-dev ?)...

Le ven. 9 avr. 2021 à 16:01, Nicolas Cellier
<[hidden email]> a écrit :
>
> 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 <[hidden email]> 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.
> >
> >



Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

stlutz
codefrau wrote
Incidentally, which library/function specifically do you want to call?
I am generating code to satisfy the OpenGL interface. The functions that are making trouble are also highly unlikely to ever be called, as they are part of outdated extensions (glLGPUCopyImageSubDataNVX, glMulticastCopyImageSubDataNV, glAsyncCopyImageSubDataNVX). That's also why I was asking and hoping for a simple solution, since it is not really worth it for me to dive deeper into this. I will probably simply ignore these methods and not generate them, and add a class comment noting their absence.
Nicolas Cellier wrote
Eliot Miranda suggested to pass first 14 arguments as usual, and only the last+excess arguments into an array, but nobody did work on such implementation. I do not remember pros and cons either, need to various scan mailing lists
Yes, admittedly I had searched the mailing list(s) before posting and found this thread: http://forum.world.st/Methods-with-more-than-15-args-sketch-td4901127.html. I just wondered if anything happened in this regard that my Generic-Search-Engine-Fu could not uncover.

Sent from the Squeak - Dev mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

Nicolas Cellier
Le jeu. 15 avr. 2021 à 15:07, stlutz <[hidden email]> a écrit :

>
> codefrau wrote
> Incidentally, which library/function specifically do you want to call?
>
> I am generating code to satisfy the OpenGL interface. The functions that are making trouble are also highly unlikely to ever be called, as they are part of outdated extensions (glLGPUCopyImageSubDataNVX, glMulticastCopyImageSubDataNV, glAsyncCopyImageSubDataNVX). That's also why I was asking and hoping for a simple solution, since it is not really worth it for me to dive deeper into this. I will probably simply ignore these methods and not generate them, and add a class comment noting their absence.
>
> Nicolas Cellier wrote
> Eliot Miranda suggested to pass first 14 arguments as usual, and only the last+excess arguments into an array, but nobody did work on such implementation. I do not remember pros and cons either, need to various scan mailing lists
>
> Yes, admittedly I had searched the mailing list(s) before posting and found this thread: http://forum.world.st/Methods-with-more-than-15-args-sketch-td4901127.html. I just wondered if anything happened in this regard that my Generic-Search-Engine-Fu could not uncover.
> ________________________________
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
You can peek the SmallapackCompiler and use it in your interface class
(declare compilerClass ^SmallapackCompiler at class side).
That's the most simple thing that could possibly work.
All code is MIT.

Reply | Threaded
Open this post in threaded view
|

Re: Methods with more than 15 arguments?

codefrau
In reply to this post by stlutz
On Thu, Apr 15, 2021 at 06:07 stlutz <[hidden email]> wrote:
codefrau wrote
Incidentally, which library/function specifically do you want to call?
I am generating code to satisfy the OpenGL interface. The functions that are making trouble are also highly unlikely to ever be called, as they are part of outdated extensions (glLGPUCopyImageSubDataNVX, glMulticastCopyImageSubDataNV, glAsyncCopyImageSubDataNVX). That's also why I was asking and hoping for a simple solution, since it is not really worth it for me to dive deeper into this. I will probably simply ignore these methods and not generate them, and add a class comment noting their absence.

That makes sense. These are highly specialized extensions for multichannel VR rendering on NVIDIA hardware in an SLI configuration. Not worth extra effort, IMHO. 

–Vanessa–