... 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 <vanessa at codefrau.net>
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 <
> nicolas.cellier.aka.nice at gmail.com> 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
>> <nicolas.cellier.aka.nice at gmail.com> 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 <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.
>> > >
>> > >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210409/35e6cc64/attachment.html>