Le Jeudi 16 Février 2006 14:51, Marcus Denker a écrit :
> On 16.02.2006, at 15:22, Jecel Assumpcao Jr wrote:
> > Andreas Raabwrote on Wed, 15 Feb 2006 22:13:26 -0500:
> >> There is no fix for this problem. In Squeak, the number of parameters
> >> for a method invocation is limited to 15.
> >
> > Not quite true (in theory) - the VI4 version of Squeak could have
> > up to
> > 256 parameters (if my quick impression of the code is correct).
> >
> > http://minnow.cc.gatech.edu/squeak/2119
> >
> > In practice Nicolas will almost certainly not want to go that route
> > given that nobody else will, so the answer is that indeed there is no
> > fix for this problem.
>
> There are a lot of upper bounds in the squeak bytecode, e.g. jump
> offset, number of temps (256), number of instVars, number of Literals...
>
> That's quite bad as soon as you try anything with code generation that
> has different properties than Smalltalk code. Or when you try to
> annotate
> code (e.g., for tracing or debugging or meta programming).
>

As long as you have a Compiler with BlockClosure, you do not need a jump 
instruction in the byte code: jump is just an optimisation.

Temporary variables and literals can each be gathered in a single array, all 
you need is #at: #at:put: #perform:withArguments, and when accessing the 
arrays, do arithmetics with small numbers so that they are not coded as 
literals themselves.

This his how I did overpass byte code limits for arbitrary complex symbolic 
expression in VW, transparently to the user (the byte code limit did raise 
exception that were handled at compiler level).
Generated code were not optimal, but it was still more efficient than 
sub-expression substitution.

Maybe I should publish it someday (some clean up necessary).
It must be transposable to Squeak I think (BlockClosure needed).

Unfortunately, this does not solve my problem of number of arguments...

> I'd love to see a vm and bytecode design with all these artificial
> limitations fixed...
> in SmalltalkX Claus extended the bytecode a long time ago to have no
> limits at all
> (offsets can grow indefinitly).
>
>       Marcus

That would be great, but i presume futur is far away...

Maybe a trick is possible at FFI level ? (pass an array of arguments)