[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

[Hal Black]

On Wed, Oct 21, 1998 at 10:52:38PM -0600, Chris Gray wrote:
> [Hal Black:]
> 
>  >One thing I'd really like to see, is have the modules made from VM code
>  >completely interchangable with modules made from native code.  That way,
>  >it would be a lot easier to replace VM code bit-by-bit with native code if
>  >you need to do so for performance purposes.  This would be especially nice
>  >if, say, the driver part was in C++, and there was a C++ to VM compiler.
>  >Then, you could swap stuff in and out of VM mode as desired for profiling,
>  >debugging, security, and so forth.
> 
> As I mentioned in an earlier note, problems arise more from run-time
> library or support environment than from strict language issues. In this
> particular instance, please note that C++ is a very large language - building
> a compiler for it is man-years worth of work. There are some available
> parsers out there, but then the problem of licensing can come up.

Oh, absolutely.  When I wanted to learn C++ I went out and read the ARM.  There
is a lot of stuff in there that is too much for the VM to do.  Let me try to
restate what I meant:
  The VM code should be replaceable by native code, but not visa-versa.

  Take the example for C++ below:

> An in-MUD language will typically have language elements that are added
> to make in-MUD programming easier. Those won't exist in external languages,
> and so that stuff would have to be translated into function calls,
> possibly quite a lot of ugly ones. As an example, the statement:
> 
>     player at hits := player at hits - weapon at hits;

    player.hits = player.hits - weapon.hits;

> Keeping the in-MUD language(s) for higher-level world/quest/NPC stuff and
> the native compiled language(s) for lower-level things is probably a
> good idea.

Agreed to keep the system-level stuff out of the VM.  But what I would like
to suggest as an idea would be to have the mud-relevant parts of the native
mode language compilable to VM code.  And not set the role for the game
engine to be "VM only".  Maybe some subset of C++ for instance would work
there.
  The main reason I'd want to do this would be for performance purposes.
For instance, if there is an operation that is costly in time that processes
in-game objects, you are kind of sunk if you only allow VM code to do that.
What I'm suggesting is interchangable versions of LPC's lfun and efuns, but
at the object level.  I believe DGD does the opposite of what I'm suggesting:
compiles Mud-Code LPC to native code.  That would be a good solution also.  I
don't know how well this would perform, however.
  The question becomes, which is easier/better?  To compile MUD VM code to
native, or to compile C++-subset code to VM bytecode?  Furthermore, what if
you used the same language (simplified C++ or Java) for both the in-game and
driver stuff?  If so, in the case of C++, you'd only have to write the C++
to bytecode compiler, plus the interface code.  If you did it in Java and
used the Java Virtual Machine, you'd only have to write the interface code
because there are Java-to-JVM and Java-to-Native compilers (though I haven't
tried any of the latter).
  If I knew enough about compilers, I'd have done this already.  Anyway, some
food for thought.