<br><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 3:36 AM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 12:19 AM, Colin Putney <span dir="ltr"><<a href="mailto:colin@wiresong.com" target="_blank">colin@wiresong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I was poking around in Compiler today, and noticed that it's a<br>
bit... messy. I had a few ideas for improvement, but before I go<br>
monkeying with such an important part of the system, I thought I'd<br>
bring it up here. Do we have a long- or medium-term plan for how the<br>
compiler should evolve?<br>
<br>
As I see it there are a few paths available to us:<br>
<br>
1. Incremental improvement. The compiler we have now is tried and<br>
true. Now that we have proper block closures and a high performance<br>
VM, there's no real need to improve bytecode generation, so we<br>
shouldn't put much effort into this part of the system. We'll just<br>
make small improvements and minor refactorings as needed.<br></blockquote><div><br></div><div>I wouldn't say that the bytecode set is satisfactory. Some things that are wrong are</div><div>- limited to 256 literals</div>
<div>- limited to 32 temporaries, 16 arguments (IIRC)</div><div>- limited room for expansion (and in Newspeak there is no room for expansion)</div><div><br></div><div>I'd like to see a set with</div><div>- 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.<br>
</div></div></blockquote><div><br>Is it not worth to also have space to store the endPC? <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div>- a design based around prefixes for extended indices a la VW. lifts the limits on addressability, arity etc while keeping the bytecode compact</div><div>- 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).</div>
<div><br></div><div>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.</div>
</div></blockquote><div><br><br>That would be lovely for proxies that proxify booleans. <br></div></div><br>Cheers,<br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
<br>