[squeak-dev] Re: Making a better Compiler for all

Igor Stasenko siguctua at gmail.com
Mon Sep 1 10:43:36 UTC 2008


2008/9/1 Klaus D. Witzel <klaus.witzel at cobss.com>:
> On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
>
>> On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
>>>
>>> Hello folks,
>>>
>>> during my visit at ESUG i had a conversation with Stephane, about
>>> different things, one of them is to make a better and cleaner compiler
>>> implementation.
>>
>> I thought this was the purpose of the NewCompiler project.
>
> No, you cannot remove Squeak's compiler and use only NewCompiler, if that
> would have been your question.
>
> /Klaus
>
>>  Is that
>> project not good enough?  Or is this a request to make it standard?
>>

Yes, the main question about it, why it didn't replaced old compiler?

There are some bad things in current compiler, which makes it really
hard to play with:
try implement a visitor pattern with its AST - you will go into
trouble very soon, because some nodes properties is not fully exposed,
or accessible in a cryptic way. That's why VMMaker, for instance,
using an extensions/patching to be able to reach all interesting
properties of parse nodes.
A bytecode generation is spead among AST nodes, and interesting, that
you can't insert some kind of analyzer or pre/postprocessor without
patching methods, because there is no separation in responsibility who
emits the bytecodes.A MethodNode returns you a hot baked
CompiledMethod instance. It would be good to make a bytecode
generation placed in separate class , which using a visitor pattern to
generate a bytecode.
There are also an agressive rewrite rules, sitting at early processing
stage which replacing original selectors like #ifTrue:{ifFalse:} or
#to:do: , so you can't see an original parsed AST from source code,
but getting already twisted preoptimized tree , which not reflects an
original source 1:1.

>> -Ralph
>>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list