You should have a look at ByteSurgeon in Squeak :)

Stef

On 16 févr. 06, at 19:59, nicolas cellier wrote:

> 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)
>
>
>