[squeak-dev] Re: Compiler

H. Hirzel hannes.hirzel at gmail.com
Wed Jun 20 11:00:59 UTC 2012


I would vote for 1, and then 'easy things first'.

"1. Incremental improvement. The compiler we have now is tried and
true. Now that we have proper block closures and a high performance
VM, there's no real need to improve bytecode generation, so we
shouldn't put much effort into this part of the system. We'll just
make small improvements and minor refactorings as needed."

I don't know if overcoming the limit of 256 literals is easy or not,
but that is something I would like to use....

--Hannes


On 6/20/12, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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 Squeak-dev mailing list