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

[Chris Gray]

[Jon A. Lambert:]

[Grrr. I sat down to work on telnet stuff tonight! Oh well! :-)]

 >But note the similarities between generating bytecode and 
 >interpretive execution. I assuming one has to make at least a 
 >scanning pass through any high level-code to do a syntax check, you 
 >might as well build the byte-code.  And make the execution a 
 >bytecode/pseudocode interpreter. Building an executable, even 
 >platform optimized native is a snap once you have a common bytecode.  
 >JIT anyone?

Nod. It all depends on how the interpretation is done, however. In
ToyMUD, I have no representation other than the raw strings, and do all
the work again and again and again. Makes for small system sources, but
it sure is slow! At the other end of the scale, AmigaMUD's initial
interpreter (before byte-code) uses a recursive routine that walks
the parse-trees in depth-first order, evaluating as it goes. It also
doesn't need to do any run-time type checking, since that was all done
by the parser. There is something to be said for having an extra
representation like that - it can be "pretty printed" back into source
form, whereas bytecode is a *lot* harder to do that with. If we allow
multiple languages, using something like a parse tree as a common
intermediate form could allow machine translation among the languages.
That may be more complexity than is warranted, however. But at least
it would let both of us have our favourite syntaxes - a flag on the
wizard character could indicate which form to use on output!

 >I don't think anyone would want to.  My idea was multiple 
 >compiler-flavors, and multiple targets 
 >(interpretation/bytecode/native), eventually... Rather than tie it
 >to a language with a fixed feature set, allow it to be extensible.

Nod. I'm not quite sure what it was you said that got me thinking you
had intended an assembler. Perhaps speaking of labels.

 >Yes, built a very simple minimal language.  Let the minimal 
 >language we come up with, self-document the bytecodes one needs to 
 >execute it.  This bytecode would be same in any language 
 >implementation. And then extend the operands as needed to support
 >generic feature sets one would desire in different high level 
 >languages.  Thoughts?

One thing to watch out for when designing a byte-code - don't waste
the opcodes! Either that or go with 16 bit (word-code) values right
away. Something that I think limits the kinds of optimizations that a
Java VM can do is that they are nearly out of byte-codes, and so the
system is restricted in the amount of extra ones they can invent. Also,
having everything be a 16 bit reference into the "constant table"
means that you can't replace instructions containing such references
with instructions containing a 32 bit run-time value. There are ways around
that, but it could be painfull.

(Why would you want to do that? Well, if you have a call from function
A to function B, such that you know at linkage time that the parameters
will always match, you can replace the function-call opcode with one
that just does a jump directly to the byte-code for the called function.
No indirection or lookup necessary. The assumption here is that once
loaded/compiled, byte-code will not move in memory.)

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