Mark Guzdial : Georgia Tech :guzdial@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
squeak-dev@lists.squeakfoundation.org