[squeak-dev] A Bootstrap Compiler
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:
>> 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
>> I wrote a longer explanation so if you are interested, please go to:
>> 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
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 :)
>> Thank you!
>> -- Yoshiki
Igor Stasenko AKA sig.
More information about the Squeak-dev