I believe that a Klein-like VM has the potential to be more object-oriented and more interactive than a Squeak-like VM. But one of the costs of the Klein approach is that we can’t reuse existing compilers the way Squeak does.
One of the cool things about the Squeak VM is that by writing it in a subset of Smalltalk, they were able to use the standard Smalltalk environment to write and debug the VM, while still taking advantage of all the work that’s gone into implementing C compilers. Writing in restricted Smalltalk is still nicer than writing in C, and debugging a simulated interpreter using the Smalltalk debugger is nicer than using a C debugger. (And while GCC isn’t written in Smalltalk, the Squeak guys don’t have to maintain it, so who cares?)
In contrast, one of Klein’s goals is to write the entire VM in a normal, high-level, object-oriented style. This includes the compiler and the assembler and the garbage collector and the interpreter (if we someday decide that we want an interpreter) and the object-format subsystem and everything else. So far, I believe we’ve only had to “cheat” (dip down into a lower-level style) in two small places: we had to write the message-sending routine without doing any message sends, and the object-cloning routine without doing any cloning (which meant we couldn’t use blocks). But I believe that even those compromises are just temporary – now that we’ve got a compiler that can inline away message-sends and block-clones, we should be able to rewrite even those two routines in a normal OO Self style.
So we’ve had to write our own compiler ourselves, and we’ll have to maintain it and port it ourselves. But the payoff is that the whole VM can be written in full OO Self, and be a live part of the running Klein image.
Which brings me to the other big difference between Klein and Squeak: in Squeak, the running VM isn’t part of the image. If you use the Squeak environment to make a change to the source code of the Squeak interpreter, the currently-running Squeak system doesn’t immediately change – you have to re-run the Slang-to-C translator and rebuild the VM and restart the image. (You can use Squeak to run a simulated Squeak interpreter, and make changes to the source code of the interpreter and see the changes immediately take effect in the simulation. But you don’t get that kind of interactiveness in the real base-level Squeak.) And if you want to debug the Squeak VM, you have to either use C tools to debug the real VM, or you have to recreate the bug in the simulator and use an existing Squeak to debug the simulated Squeak.
(Someone please correct me if I’m wrong. I haven’t spent a lot of time playing with the Squeak VM. This is just how it seems to me, given my understanding of Squeak’s architecture.)
In contrast, the Klein VM code is all just a regular part of the running Klein image. The project isn’t far enough along yet for us to be able to hack on Klein while it’s running, but once we get there, we should be able to make changes to the running VM and see those changes take effect immediately. (I expect this to be both very useful and very dangerous – a tradeoff Smalltalkers are used to. :)) So when we debug the Klein VM, we’re looking at the real, running, compiled code, using the standard Self environment.
A third difference is that in Klein we intend to – and for performance reasons we pretty much have to – implement Self’s dynamic optimization tricks, whereas I don’t think the current Squeak VM does much of that kind of thing. But I don’t think that’s a fundamental limitation of the Squeak VM architecture. (I’m excited about Cog!)
Self 