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

[Jon A. Lambert]

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
                  POP R2
                  ADD R1,R2			  
                  PUSH R1

Interpreter:  a = pop();
              b = pop();
              x = addops(a,b);
              push(x);
			
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.  
JIT anyone? 

> 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 
languages.  Thoughts?



--
--/*\ 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   /*\--