On Wed, Dec 29, 2010 at 1:29 AM, stephane ducasse <
stephane.ducasse at gmail.com> wrote:

> Eliot
>
> I would love to see that during the school at INRIA. Could you have a
> session on that?
>

Sure.  I'm hoping that I can set some assignments and have people try and
build stuff.  So this would be a good point to start from and head in the
direction of bootstrapping an image.


> Because we need to use a better infrastructure to build new image.
> BTW: I had the same question regarding the use of the C compiler. What we
> tried with the students here was to use the system itself
> but we could not work full time on it and also we started from a larger
> kernel (and wanted to remove more - big mistake).
>
> Stef
>
>
> > 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/squeak-dev/attachments/20101229/5bdc6165/attachment.htm