[MUD-Dev] byte-code anyone?

[Jon Leonard]

On Wed, Feb 11, 1998 at 11:15:06PM +0000, Chris Gray wrote:

[problem involving lots of computation in a MUD (world generation)]

> to be done on it, however (it's pretty cantakerous about settings). I've
> been doing it within my MUD server, mostly because that's convenient - if
> I mess up, nothing crashes, and the access to graphics is trivial (I need
> Java, I know!).

> My problem with the way I do it is that it is waaaay too slow. So, having
> just finished reading the Java Virtual Machine book, I decided it would
> be fun to add a byte-code system to my server. So, I've started out on
> that. I've done sort-of similar things before, but never one quite like
> this one (designed to do certain things as fast as possible).
>
> Any general comments or discussions out there on this sort of thing? Have
> any of you done true byte-code systems before? How did they work out?
> I'm not looking for source code or anything like that - that would take
> the fun out of it! That may sound a bit wierd, but keep in mind that I'm
> in the MUD area simply because its can be a fun area to program in.

I've been implementing something similar in the MUD I'm writing, but I
realized fairly early on that I could get even better speedups by compiling
all the way to machine code instead of just to bytecode.  (What JIT runtimes
do for Java)

This sort of thing is well covered in compiler textbooks -- there's a
source language, possibly and intermediate code, and an output code.  The
twist that a bytecode adds is that the target machine is virtual, and
supposedly proof against crashing.  My favorite compiler book is
_Compilers, Principles, Techniques, and Tools_ by Aho, Sethi and Ullman.

My recommendations would be more complete if I were done, but here's the
advice I'm giving myself:

1) Test the virtual machine carefully starting early on, so fewer bugs need
  to be laboriously traced by single-stepping an interpreter.

2) Design so that no matter how perverse the byte codes you get fed are,
  you don't crash or violate security assumptions.  Going from an interpreted
  language to byte codes or machine code makes demonstrating correctness
  much harder.
 
3) Pick carefully what the simple primitives are.  Missing a vital one
  can cost lots of performance, but too many bloats your
  interpreter/compiler/security model.

4) Don't expect to be done soon.  A compiler can be a lot of work.

If there's interest in my example code to generate C, compile it, and
dynamic link it in, I'll clean it up an stick it on my web page.  It
relies on the dlopen calls of modern UNIXs (tested on Linux), so it's
probably not of use to Chris.  (AmigaDos port coming after all my other
projects...)

Jon Leonard