[Vm-dev] Re: [squeak-dev] A Bootstrap Compiler

[Eliot Miranda]

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

 Thank you!
>
> -- Yoshiki
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101228/94ed9494/attachment-0001.htm