[Vm-dev] Re: Compiler

Bert Freudenberg bert at freudenbergs.de
Wed Jun 20 09:35:11 UTC 2012

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.

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.

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 -

More information about the Vm-dev mailing list