[squeak-dev] A Bootstrap Compiler

Igor Stasenko siguctua at gmail.com
Tue Dec 28 23:22:34 UTC 2010


On 28 December 2010 19:22, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Yoshiki,
>
> On Tue, Dec 28, 2010 at 2:19 AM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
>>
>>  Hi,
>>
>>  We've been playing with John's MicroSqueak and it occured to me that
>> having a bytecode compiler that is implemented outside of Squeak opens
>> some possibilities, such as generate a growable image file from all
>> text files, or make deep changes to the system without shooting
>> yourself.
>>
>> I wrote a longer explanation so if you are interested, please go to:
>>
>> https://github.com/yoshikiohshima/SqueakBootstrapper
>>
>> and check it out.
>
> I simply don't see the benefit of putting energy into other languages.  I
> see the benefit of a textual bootstrap.  But why is it worth-while
> implementing that in C instead of Smalltalk?  If Smalltalk is more
> productive (which it is) then writing such a bootstrap in C is a waste of
> effort, reinvents several wheels at considerable expense and produces an
> artifact that is less flexible, less extensible, less useful than
> implementing the same functionality in Smalltalk.
> On the other hand, as Andreas suggests, trying to implement something using
> the simulator looks to be really powerful.  Recent;y I've been playing
> tangentally in this area.  In recent days I've produced a new code generator
> for Cog that has some useful speedups (Compiler recompileAll ~ 9% faster,
> benchFib 2x).  To test the code generator I needed to check stack depths at
> various points in JIT compilation and execution of the JITted code.  I have
> a Smalltalk class StackDepthFinder that answers the stack depths for each
> bytecode of a method.  By adding two classes VMObjectProxy and
> VMCompiledMethodProxy I could apply StackDepthFinder to methods in the
> simulator's heap and hence derive stack depths for any method in the
> simulators image.  To test the JIT it was also convenient to be able to JIT
> methods in my work image, synthesised test cases etc, not just methods in
> the simulated image.  Again a facade class allows the simulator to JIT any
> method in my work image.  This worked well and was easy to implement.
>  Extending in this direction seems straight-forward.
> One starts up wit a simulator and an empty heap and bootstraps objects into
> that heap, using whatever bytecode set and object format one chooses.  One
> can test the image using the simulator which should be quite fast enough if
> the image is a small kernel.  All the implementation is useful and adds to
> the simulator/VMMaker ecosystem.  All the code is Squeak and can reuse
> substantial parts of the system.  Seems like a win to me.  I think I'll take
> this approach in implementing the new object format.  It could be a new
> backend to MicroSqueak.


Likewise, in NativeBoost, to debug a generated native code, i simply
instructing
assembler to generate int3 instruction at point where i need, and then
after accepting a method and
running the doit, which using this method, i pop into debugger (like
gdb) and can step by step see what it does..

I don't remember being able to do that from any other language,
because code-compile-run cycle makes it simply impossible.
Ah yes.. there is 'compile and continue' feature for C.. but i never
used that after couple failures. And besides often compile & continue
takes same time to compile things than simply build everything from
scratch.. so at the moment when it done compiling, you can forget what
you doing there :)

> cheers
> Eliot
>>
>>  Thank you!
>>
>> -- Yoshiki
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list