On Oct 31, 2007, at 6:00 PM, Andreas Raab wrote:
tim Rowledge wrote:
Yes, we could probably rewrite a lot of code currently in C source files and put it into Slang methods. Yes, we could probably improve Slang (we tried to get some of that done at Interval but ran out of time) to be more friendly. Yes, we could do lots of things. Got time to do them? Or money to pay me/Craig/Andreas/Ian/John/Mike/ Bryce/whoever to do it fulltime? That's the kind of thing that would be required to be able to make any major changes
Well, but let's not throw out the baby with the bath water. Improvements would be welcome, in particular if they are easy to review and to integrate. It is probably unwise to start this as the lets-rewrite-the-vm-and-its-tools-from-scratch approach but there are plenty of things that we could do better. For example, I would welcome a patch that enables the code generator to optionally build the entire VM as an object. That'd be a very nice stepping stone towared a multi-threaded VM and can probably be done in a fairly incremental way.
I had some code a while ago that generated the entire VM as an Objective-C object, with the actual class hierarchy (ObjectMemory -> Interpreter ) still intact. It interpreted a couple of thousand byte codes until it hit a function that had been generated from literal C code embedded in the Smalltalk code for the VM. I gave up at that point because there turned out to be quite a bit of that literal code that would need to be rewritten, as it would probably need to be for any such effort unless these C snippets have since been replaced.
Now that we seem to be seriously discussing turning the VM into an object, I would suggest at least having a very close look at leveraging Objective-C, and yes, I can hear the virtual groans ;-) Anyhow, here it goes:
First, unlike the C++ approach there are no problems in terms of linkage compatibility: Objective-C behave just like C in that respect. I also don't see any speed issues, because Objective-C methods are just C functions with some extra metadata and some implicit arguments. So functions can still be called and inlined pretty much exactly the way they are now. (This would entail either generating the functions and adding the metadata to make them known to the runtime or generating methods and getting function pointers from the runtime. Either approach would work, with the former possibly retaining better C compatibility).
Speaking of compatibility: despite the rumors, Objective-C is not an Apple/MacOS-X thing. It comes with gcc and AFAIK most every 32 (and 64?) bit platform gcc supports. Furthermore, as I alluded to before, and unlike C++, Objective-C isn't really a new language per-se, it really is just C with an object-runtime library that works just as well from C and largely optional syntactic sugar.
So if there's so little difference, what's the upside? Well, the runtime does come with all or most of the niggly details you need for on OO system. So on the purely practical side, you can instantiate multiple objects (interpreters, plugins), load classes (plugins again). If you have multiple instances of the interpreter, you can also have subclasses of the interpreter, override methods on-the-fly, do introspection etc. Plugins can be just objects, with the plugin interface regular messages sends. Etc.
Then there's all that with syntactic and semantic similarity, passing messages between the VM and the programs it is running (nice metacircularity...) and so on and so forth.
Anyway, just my € 0.02
Marcel