[Vm-dev] Re: [squeak-dev] Compiler

Mariano Martinez Peck marianopeck at gmail.com
Thu Jun 21 16:53:52 UTC 2012


On Wed, Jun 20, 2012 at 3:36 AM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Tue, Jun 19, 2012 at 12:19 AM, Colin Putney <colin at wiresong.com> wrote:
>
>> So I was poking around in Compiler today, and noticed that it's a
>> bit... messy. I had a few ideas for improvement, but before I go
>> monkeying with such an important part of the system, I thought I'd
>> bring it up here. Do we have a long- or medium-term plan for how the
>> compiler should evolve?
>>
>> As I see it there are a few paths available to us:
>>
>> 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 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)
> - limited room for expansion (and in Newspeak there is no room for
> expansion)
>
> 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.
>

Is it not worth to also have space to store the endPC?


>
>
- 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).
>
> Even more interesting would be metadata that allowed the discovery of
> inlined blocks so that e.g. mustBeBoolean is instead handled by dynamically
> creating closures and the relevant ifTrue:ifFalse: message so that these
> can be inlined for true/false but reimplemented for other objects.
>


That would be lovely for proxies that proxify booleans.

Cheers,

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120621/e7814327/attachment.htm


More information about the Vm-dev mailing list