Bootstrapping "Optimizing Squeak"
patc at Teleport.com
Fri Feb 26 17:00:32 UTC 1999
>Mark Guzdial : Georgia Tech :guzdial at cc.gatech.edu
>I have been reading the "Optimizing Squeak" thread with great interest,
>though not always with great understanding :-) Playing with different VM
>architectures and alternative bytecodes sounds like enormous fun and a
>really powerful student project.
>How does one actually move to a new bytecode set? What is the path by
>which you say "Okay, recompile all the code in the system using my new
>compiler in order to create a new image for my new VM"? The Digitalk
>people had to do this at least once, didn't they? Or do new bytecode sets
>typically retain some backward compatibility while bootstrapping?
First you write a new bytecode compiler that will generate your new
bytecodes. Then you can modify the cloner to replace the compiled method
objects with new ones that were created by your new compiler. This is the
classic way of doing it. However the bytecode set that Allen W-B
published was used in the first firewall experiments. This build a new
image from the sources. We had some very small images running using this
technology to make small programs with only a few methods. images of less
That byte code set was for compiled code. It was possible to interpret it
for debugging the compiler but it was slow because of the labels. We
wanted labels for compiling because they indicated the branch targets.
(You have to watch optimizing across branch points.) But when
interpreting you had to scan the whole method to find the label. To speed
up interpretation you could add a array which was the bycode pointer for
each label. Since the labels were very small integers the indexing would
be trivial. However it would increase the size of the method by one
object plus 4 bytes for each branch target.
More information about the Squeak-dev