[MUD-Dev] Re: Bruce Sterling on Virtual Community goals
Jon A. Lambert
jlsysinc at ix.netcom.com
Tue Oct 20 23:49:17 New Zealand Daylight Time 1998
On 19 Oct 98, Chris Gray wrote:
> >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.
Nod. So have I. Referring back to the Crenshaw tutorial, so did he.
The only reason I bring it up the idea of starting with a standard
and minimal bytecode, is that at some point in
compilation or interpretation you will generate:
Pseudo-machine : POP R1
Interpreter: a = pop();
b = pop();
x = addops(a,b);
Or something that makes more sense...
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.
> 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?
True very true. It's certainly possible to generate bytecode that
fails miserably at runtime. There are tradeoffs. If the compiler
has strong-typeing the runtime checks can be disabled, if the
compiler has weak-typeing the runtime checks/conversions/promotions
must be done. Another parameter for the VM.
> 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?
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.
>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.
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
--/*\ Jon A. Lambert - TychoMUD Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
More information about the MUD-Dev