[MUD-Dev] Re: Bruce Sterling on Virtual Community goals

[Chris Gray]

 >You're right.  I think a better way to approach an extensible 
 >(generic?) internal mud language is to design the VM first.  More 
 >particularly a byte-code assembler.  From there, anyone could create 
 >a compiler for their favorite language du jour.   If you prefer 
 >strong typing over weak typing, the compiler would simply ignore or 
 >not generate opcodes that deal with type promotions/conversions.

I did mine in the exact opposite order, and am pleased with the result.
I parsed into data structures, and only recently have I translated
into byte-codes. I view byte-codes as a largely irrelevant internal
implementation detail, and there is no way for the users to enter
them, other than through the programming language. There is a
'disassemble' builtin that I've used for debugging, and will leave in
just for interest's sake.

The disadvantage of what you suggest is that you are throwing away a
good portion of the possible speed. One reason is that it is the lack
of any need for run-time checks (other than things like divide-by-zero)
that makes my byte-code so much faster than, say, Java byte-code. I
figure the only reason to use byte-code rather than some other interpretation
scheme is because you want maximum speed. So, why then cripple that speed?

Inventing a byte-code and then doing something like an assembler for it,
is doing a whole lot of work that there really isn't a need for. Why
would anyone want to program in byte-code assembler? If the byte-code
is tuned to the higher-level language, then the compiler-generated stuff
will be just about as fast as any hand-coded stuff, even without a
fancy compiler. Remember the result I posted a month or two ago about
my byte-code running only 12 times slower than native code for some
tests? You won't get that if you burden it with run-time byte-code
validity checks, type checking/conversion, parameter checking, etc.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA