<div dir="auto">... 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. </div><div dir="auto"><br></div><div dir="auto">Incidentally, which library/function specifically do you want to call? </div><div dir="auto"><br></div><div dir="auto">Vanessa</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 09:43 Vanessa Freudenberg <<a href="mailto:vanessa@codefrau.net">vanessa@codefrau.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Yep, that’s how it should work (array as 15th arg). I guess it would be relatively simple to make the encoder do that. </div><div dir="auto"><br></div><div dir="auto">Vanessa</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 07:14 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note that Smallapack passes all arguments into a single array.<br>
Eliot Miranda suggested to pass first 14 arguments as usual, and only<br>
the last+excess arguments into an array, but nobody did work on such<br>
implementation. I do not remember pros and cons either, need to<br>
various scan mailing lists (squeak or vm-dev ?)...<br>
<br>
Le ven. 9 avr. 2021 à 16:01, Nicolas Cellier<br>
<<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br>
><br>
> You can see a workaround at <a href="http://www.squeaksource.com/Smallapack.html" rel="noreferrer" target="_blank">http://www.squeaksource.com/Smallapack.html</a><br>
> See package<br>
><br>
> Smallapack-Compiler.trunk-nice.6.mcz<br>
><br>
> Le ven. 9 avr. 2021 à 13:28, Stephan Lutz <<a href="mailto:dev@stlutz.net" target="_blank">dev@stlutz.net</a>> a écrit :<br>
> ><br>
> > At the moment methods are limited to 15 arguments at most.<br>
> ><br>
> > Trying to compile a method with more arguments fails:<br>
> ><br>
> > 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<br>
> ><br>
> >     ^ 42<br>
> ><br>
> > This limitation is enforced in Encoder >> bindArg:<br>
> ><br>
> > bindArg: name<br>
> >     "Declare an argument."<br>
> >     | node |<br>
> >     nTemps >= 15<br>
> >         ifTrue: [^self notify: 'Too many arguments'].<br>
> >     node := self bindTemp: name.<br>
> >     ^ node nowHasDef nowHasRef<br>
> ><br>
> > Looking at where this limitation comes from, I noticed that a method header only has 4 bits reserved for the number of arguments:<br>
> ><br>
> > header<br>
> >     "Answer the word containing the information about the form of the<br>
> >      receiver and the form of the context needed to run the receiver.<br>
> ><br>
> >         sign:1 29-28:accessModifier 27-24:numArgs 23-18:numTemps 17:largeFrameFlag 16:hasPrimitive 15:isOptimized 14-0:numLits"<br>
> ><br>
> >     ^self objectAt: 1<br>
> ><br>
> > This, however, only uses 32 bits in total. In a 64bit image, the other 32 bits seem to be unused.<br>
> ><br>
> > Question: Is the limit of 15 arguments still accurate on modern VMs & bytecode sets?<br>
> ><br>
> > Stephan<br>
> ><br>
> ><br>
> > 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.<br>
> ><br>
> ><br>
<br>
</blockquote></div></div>
</blockquote></div></div>