>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 
than 32K. 

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.

Pat Caudill