On Tue, Jun 19, 2012 at 12:19 AM, Colin Putney <colin@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.

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