2012/6/20 Bert Freudenberg <bert at freudenbergs.de>:
> On 2012-06-20, at 03:36, Eliot Miranda wrote:
>
>> I wouldn't say that the bytecode set is satisfactory.  Some things that are wrong are
>> - limited to 256 literals
>> - limited to 32 temporaries, 16 arguments (IIRC)
>
> In theory 64 temps, in practice a unary method can have at most 56 temps, but that's shared with the stack, so if you are sending a message with 9 arguments it's only 46 usable temps. To overcome this we would need larger context objects. Not sure how hard-coded that is in the VM.
>
>> - limited room for expansion (and in Newspeak there is no room for expansion)
>
> I would add:
>
> - limited to 1k jump distance
>
>> I'd like to see a set with
>> - a primitive bytecode to move the primitive number field out of the header and make more room for num args, num literals (64k would be a fine limit) etc.
>> - a design based around prefixes for extended indices a la VW.  lifts the limits on addressability, arity etc while keeping the bytecode compact
>> - some mild experiments such as a nop which can be used e.g. to express metadata that guides the decompiler (this is a to:do:, etc).
>
> I have run into these hard limits, too. My idea was to hack the compiler on the image side using the current byte code set. E.g., if there are more than 255 literals, use the 256th as literal array and generate code that pulls the literal out of that array (and if needed performs the send). Similarly for temps.

Yes, I did that, and even your index for accessing into the big
literal array could become too big and thus be itself a literal, so
you have to cheat and recursively build array of array of ... or
calculate the index too from smaller byte-encoded literals
(fortunately, * and + don't consume a literal, they are special):)

>
> Extending the jump distance is harder. One could imagine "jump pads" sprinkled throughout the compiled method so there would be several hops for one jump. Seems to be hairy though. Or possibly one could compile the blocks that exceed the max distance as actual blocks + message sends.
>

I did all that in VW too because I wanted to generate bytecodes for
re-evaluating arbitrarily complex symbolic expressions. For the jump,
it was easier because the block is just stored in literals rather than
inlined into the compiled method, and you don't need to jump to
evalutate such block, so you just have to turn block optimization off
in compiler with a flag.

> This would allow large methods to compile, but methods exceeding the limits would be slow. For the generated code where I needed it that would have been fine, and saved considerable effort (I had to change the code generation to break up large methods into smaller ones, with temps spilling over into instance variables, and thisContext magic to emulate local returns).
>
> So if someone wants to have fun with the compiler, working around (some of) these limits would be great. And if we get a new bytecode set, the code would become faster, too.
>
> - Bert -
>

Isn't there yet another limitation, the stack depth ?

Nicolas