[MUD-Dev] Virtual machine design

[Alex Stewart]

> 1) A java virtual machine, running compiled java (or java-like) code
> 2) Adapt an existing virtual machine from another mud to my needs
> 3) Write my own virtual machine, and make it a target for the egcs
>    compiler, thus allowing it to run byte compiled C/C++ code.
> 4) Write my own virtual machine, and write my own mud language.
> 
> Am I missing any options here?

5) Write a virtual machine independent of any source language and allow
multiple language compilers to be written for it.

This kinda falls into both 3 and 4 in some respects..  You will, of course,
need to have some basic language as a starting point, but if it's flexible
enough you don't need to be stuck with any one option foreverafter (it also
means you can develop your language or techniques for programming over time,
after seeing what works best for your situation).

> The java option has some appeal, I must admit. However, sticking to the
> jvm spec is both a plus and minus I guess. At least I have something to
> work from, but it's also rather restrictive. On the up side, there's no
> need to write a compiler. I know some people were talking about using a
> jvm for the devmud vm though, so if they have any thoughts, I'd love to
> hear them.

Frankly, I think you're looking at things the wrong way around here.  Writing
compilers with current tools isn't that hard, really.  What's hard is designing
a good, efficient, well-designed VM to execute the code, and that's what's most
important too, since programmers compile code once, and users run code over and
over and over again.

If you're considering taking advantage of existing solutions, the best reason
to do so, in my opinion, would be to take advantage of the existing VM
technology.  Writing your own JVM wouldn't do that.  On the other hand, linking
your MUD system to third-party JVMs might provide some advantages.

The two problems here are that 1) third-party JVMs generally still aren't that
good (especially freely-available ones) and 2) The Java VM design might end up
putting significant constraints on other aspects of your system.  The obvious
advantage, however, is that as new JVM technology becomes available you can
take advantage of it.

> Adapting a virtual machine from another mud seems like the least work,
> but I question how well it would work. I'd most likely have to also
> adapt the language that those muds use. If I liked the availible
> choices at present, I wouldn't want to make something new. So I don't
> think this would be a good choice.

Well, there's more to a MUD than it's language/VM.  Admittedly, if your reason
for doing this is to have a new language/VM, then this is probably a
non-option.  The other problem is that most MUD VMs are built around various
assumptions about the rest of the system, so it'd probably be a lot more work
to convert one than it looks like from the outside.

> The vm that is a target of gcc/g++ is what I'm really thinking about
> doing. It would have the advantage of the same code compiling to either
> byte code or native code, which appeals to me greatly. And there would
> also be nothing stopping me from writing a compiler for some other
> language should I decide to do so. In short, this option seems to give
> the greatest flexibility for the least amount of work. And knowing that
> quake3 (although not a mud) uses a similar approach (with the lcc
> compiler I believe), makes me think I'm right. Or am I?

This is an interesting possibility.  The one word of warning I'd offer is to
look at whether C/C++ is really the right language for working with the other
features of your MUD's programming environment (there's more to an environment
than the language.. there's a lot of implicit assumptions about the way data is
organized, access restrictions, functionality, etc.  Depending on how the rest
of your system works, some of the assumptions in the C/C++ languages may cause
problems).  Ultimately, you probably wouldn't be able to compile the same code
to native object code without some work (either modification or thunking) as
the "internal" interface to the MUD is not going to be the same as the "behind
the scenes" interface.

> The final option is probably a poor one, since the real problem with it
> is (IMO) that people would rather not learn a language that's only
> useful on a particular mud. They're more likely to use C/C++ which they
> already know, or will be useful to them elsewhere if they learn. Thus
> I'm wary of a making something that doesn't offer a "standard"
> language, at least as an option (whether that be C/C++/java/whatever).

All I have to say for this is that it's worked for a lot of other systems.  As
long as the language involved isn't too arcane, I really don't think most
programmers will have too much problem with the small added investment of
becoming familiar with a slightly different language.  They'll have to become
familiar with whatever the rest of your environment is anyway, which is the
real hard part.  In fact, as I mentioned above, it may actually be easier for
people to work in a language which is properly tailored to the rest of the
environment instead of "well, it's C++, but it's not really C++ because this is
different, and this, and this, and watch out for this because..."

> Any thoughts from people who have been through this? What choice did
> you make and why?

Well, I haven't actually "been through it"..  I guess technically I'm going
through it with my current MUD project (except, of course, that my current MUD
project hasn't been going much of anywhere for a while).  I have worked with
several systems with their own languages and VMs, and in my current project I'm
going with basically my option 5 above (the VM is a stack-based interpreter
design intended to be language-agnostic and the basic (starting) programming
language to go with it is more or less a direct parallel to the bytecodes (sort
of an assembly language).  The system will support writing additional language
compilers in-DB, so people can do whatever they want with the end product)

-alex
-------------------------------------------------------------------------------
     Alex Stewart - riche at crl.com - Richelieu @ Diversity University MOO
                         http://www.crl.com/~riche
           "For the world is hollow, and I have touched the sky."


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev