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

[Jon A. Lambert]

On 20 Oct 98, Chris Gray wrote:
> [Jon A. Lambert:]
> 
>  >I don't see why an interpreter would not look vitually identical to a 
>  >VM that processes bytecode.  An interpreter would normally use 
>  >lazy evaluation and so could the bytecode generator.  That is code 
>  >generation or execution would occur at the same points in the 
>  >execution of the interpreter/code generator.  Possibly just a 
>  >flag could control what output is desired.  State information saved 
>  >for interpretation (labels) would just as easily be used in 
>  >generating bytecode.
> 
> Not sure what you are getting at with "lazy evaluation". 

You don't have to produce byte code at every action.  You can
return information to the caller in a recursive descent parser.
Execution of an interpreted language would occur as you hit all the
returns from your recursive calls.  Delaying bytecode production
until this point puts all your code generation/interpreted execution
in the same place.  I'll have to work up some examples to explain
better. :(

>Not compiling
> to bytecode until the function/module is called? 

Depends.   It was suggested earlier, we might be generating a runtime 
interpreter.  If not, then this doesn't make sense.  

>Labels? What for you
> need labels?

Really you don't.  I was thinking of easier Pretty printing and 
decompilation?  

> 
> Fwap! (ala Gulliver's Travels)
> 

hcuO! 

>  >Details:
> 
> Are these of the HLL or the bytecode? Things like control structures and
> looping structures aren't needed in the byte code if you just have
> PC relative branches like Java bytecode does.

Yep. A Branch on Condition is all that's required!

> No labels are needed
> unless you plan on having an assembler, which I think is a bad idea.

You gotta have an assembler for those who want to touch the virtual 
metal. ;)  An assembler is probably only useful for quick testing 
of the bytecode.  This is something so simple to produce, if and 
when needed, it's not worth giving it a second thought.  In fact, 
labels are probably an artifact of the assembler and belong there.    
 
> Going straight from parse trees to byte-code isn't that bad. My stuff
> is under 1200 lines for that, and it includes several special cases
> for optimization. Also, at the level of byte-code, symbols shouldn't
> be needed. If you have to look things up in tables at runtime, then
> you are again discarding much of the speed of bytecode. Locals and
> parameters can be just offsets from a frame pointer for a stack machine.
> You can keep the symbols for them around if you want to have symbolic
> disassemblies, but stripping them out works fine too. Symbols are
> needed when resolving newly loaded stuff, as you have discussed.
>

Aye. I've looked at your stuff. :) 

[snipped discussion of linkage alternatives]

I'm not sure what to think.  All the options look good to me.  
Anyone else? 
--
--/*\ 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   /*\--