FFI problem: too many arguments
nicolas cellier
ncellier at ifrance.com
Sun Feb 19 10:45:00 UTC 2006
Le Dimanche 19 Février 2006 01:42, Dan Ingalls a écrit :
> >There is no fix for this problem. In Squeak, the number of parameters for
> > a method invocation is limited to 15.
>
> I think there may be a relatively simple solution for extending the number
> of arguments to 31. I realize that it is only a factor of two, and folks
> may consider it not worth worrying about this unless all limits are to be
> relieved but, if I'm correct, I'd be remiss if I didn't point this out.
>
> It looks to me like the method headers can take another bit of argCount as
> is, and the double-extended-do-anything bytecode can specify up to 31
> arguments on a send. I added the DEDA bytecode for other reasons, and may
> just never have bothered extending argcount at the time, figuring such code
> is, um, not generally found in Smalltalk programs.
>
Very true, lot of arguments surely indicate lack of an abstraction level
(think of creating a new class).
This was just in case of external world linking. We cannot change external
world, we must adapt.
> So if I'm not mistaken about the argCount bits in the method header and
> the DEDA bytecode, all that remains is a bit of compiler work and a few
> methods in CompiledMethod which shouldn't add up to more than an hour or
> two for someone who knows the territory.
>
> FWIW
>
> - Dan
I have another idea (workaround): fake this limit passing a single array
argument:
- transform method calls (recvr key1: arg1: ... keyn: argn) into (recvr
key1:key2:keyn: {arg1. arg2. ... argn})
- transform method implementation: argj would be replaced by (arg1 at: j)
This can be done transparently at code generation from ParseNode.
Some class like MessageAsTempNode can easily do the work.
So i started inquiring bytecode generation and found this: the DEDA you are
speaking of also have a limitation to 256 variables. And i did not see these
limitations enforced anywhere in the code.
Only the single byte code limit is tested for in LeafNode>>#code:type:, and
the code for DEDA is temporarily encoded (type*256+index). Should index
overpass the 256 limit, there might be strange results, changing the type of
operation and probably crashing the VM...
Protecting this code would be easy
(index > 255) ifTrue: [self error: 'bycode limit exceeded'].
Maybe i missed a protection elsewhere ? I will try to exhibit a test case
latter.
More information about the Squeak-dev
mailing list
|