<div dir="ltr">Please have a look at my closure compiler. This puts bytecode generation into a separate class (a subclass of Encoder).<div>You can find the code on the download page of my blog.</div><div><br></div><div>Marcus Denker and I are in agreement that we will merge my Closure compiler into Markus' NewCompiler "some time soon".</div>
<div><br></div><div>The thought of a committee fills me with horror :) I don't think we need anything so baroque :)</div><div><br></div><div>Best</div><div>Eliot<br><br><div class="gmail_quote">On Mon, Sep 1, 2008 at 3:43 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2008/9/1 Klaus D. Witzel <<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>>:<br>
<div><div></div><div class="Wj3C7c">> On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:<br>
><br>
>> On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:<br>
>>><br>
>>> Hello folks,<br>
>>><br>
>>> during my visit at ESUG i had a conversation with Stephane, about<br>
>>> different things, one of them is to make a better and cleaner compiler<br>
>>> implementation.<br>
>><br>
>> I thought this was the purpose of the NewCompiler project.<br>
><br>
> No, you cannot remove Squeak's compiler and use only NewCompiler, if that<br>
> would have been your question.<br>
><br>
> /Klaus<br>
><br>
>> Is that<br>
>> project not good enough? Or is this a request to make it standard?<br>
>><br>
<br>
</div></div>Yes, the main question about it, why it didn't replaced old compiler?<br>
<br>
There are some bad things in current compiler, which makes it really<br>
hard to play with:<br>
try implement a visitor pattern with its AST - you will go into<br>
trouble very soon, because some nodes properties is not fully exposed,<br>
or accessible in a cryptic way. That's why VMMaker, for instance,<br>
using an extensions/patching to be able to reach all interesting<br>
properties of parse nodes.<br>
A bytecode generation is spead among AST nodes, and interesting, that<br>
you can't insert some kind of analyzer or pre/postprocessor without<br>
patching methods, because there is no separation in responsibility who<br>
emits the bytecodes.A MethodNode returns you a hot baked<br>
CompiledMethod instance. It would be good to make a bytecode<br>
generation placed in separate class , which using a visitor pattern to<br>
generate a bytecode.<br>
There are also an agressive rewrite rules, sitting at early processing<br>
stage which replacing original selectors like #ifTrue:{ifFalse:} or<br>
#to:do: , so you can't see an original parsed AST from source code,<br>
but getting already twisted preoptimized tree , which not reflects an<br>
original source 1:1.<br>
<br>
>> -Ralph<br>
<div><div></div><div class="Wj3C7c">>><br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br></div></div>