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

[Jon A. Lambert]

On 20 Oct 98, Jon Leonard wrote:
> On Tue, Oct 20, 1998 at 11:58:27AM +0200, Niklas Elmqvist wrote:
> > On Mon, 19 Oct 1998, Jon Leonard wrote:
> > > That said, I think some sort of byte-code machine makes a lot of sense
> > > as an option.  Which buzzwords do we want to start with?
> >
> > Umm, do I get to pick? :)
> 
> If no one else has an opinion, yup.  :-)
> 
> > Efficient and garbage collected are two, and
> > threaded should not be too hard to tack on... And a stack-based VM like
> > the JVM sounds pretty good.
> 
> I asked because I don't think it's obvious.  My current interpreter is
> neither threaded nor stack-based.  (It isn't efficient, either, but let's
> ignore that.)
> 
> The issues for these buzzwords as I see them:
> 
> Efficient:  May make the VM harder to understand.

Nod.  I'm for completely ignoring optimization until last.  It gets 
in the way of simplicity and design flexibility.  Let's compromise 
and put in run-time profiling that can be switch-operated in or out.  
When you get to optimizing, you'll know exactly what, where, how and 
why.

> Garbage collected:  Some languages prefer the malloc/free model, and some
> 	run with static allocations.  These don't benefit from a garbage
> 	collector (but would benefit from resource tracking:  At end of
> 	thread, collect any malloced but unfreed space, etc.), and would
> 	pay a performance penalty if it were enabled.  Similarly, type
> 	taging for tracing pointers or some replacement technique is
> 	required.  (And anything better than reference counting can be
> 	fairly hard to follow.)

Don't know.  If all variables are stack-based or local, GC doesn't 
matter much.  Variable lifetime and scoping need to be defined.

> Threaded:  If we want the VM itself to be multithreaded, then we need
> 	locking for various parts of the VM.  There's a real performance
> 	cost there.  I'd like at least a compile time option to turn it
> 	off for uniprocessor machines.

Aye.  A optional feature switch is a good idea.

> 	Being able to run multiple threads of the bytecode is a must.
> 	This can be implemented using something like cooperative multitasking,
> 	or even just forcing each bytecode operation to complete before
> 	doing something else (interrupt, other thread, etc.).

I mentioned some issues in an earlier post.  

> Stack-based:  This does pointless, inefficient things to continuation-passing
> 	languages.  It also doesn't map well into superscalar hardware, but
> 	I don't forsee doing custom hardware for the bytecode.

Once again, defer optimization... stack-based can be both simple and
contain potentially wasteful repetitive operations.  But once you 
have a working machine lazy evaluation and other optimizaions can be 
explored in depth. 

> >
> > Or you could implement this in C++, and you'd be doing some things a
> > little different. I'm not about to start a religious language war here
> > (hopefully), but I think the O-O nature of C++ lends itself perfectly to
> > an object-oriented environment such as a MUD. When I did my first server
> > effort in C, I found myself writing object-oriented C code most of the
> > time :)
> 
> (Normally I'd just not comment on language issues, but in this case we do
> need to pick an implementation language.  Our esteemed list owner may have
> to tell us if we get too far off topic.)

My guess is there are two camps, C and C++.  Noone has suggested
anything else.  I prefer C++, but would be willing to do C without 
the tricks and shorcuts that would make a C++/Java co-version 
implementation very difficult to maintain.

> I think some C++ charateristics are incompatable with what we want to do:
> 
> 1) The C++ object model is unique to C++, and using C++ objects from another
> 	language requires writing wrappers that use C bindings.  C++ naming
> 	conventions aren't even consistent between compilers, and prevent
> 	other languages calling objects directly.
> 
> 	If we're going to have C bindings for things, (necessary for
> 	supporting in-game languages like Perl, Python, TCL, etc.) then
> 	I don't see the point in building separate C++ interfaces.

I thing C call bindings are probably necessary for it to be a 
bonafide plugin to any existing project..
 
> A proposed basic module interface:
> 
> With the exception of a bootstrap module, all modules can be loaded with
> dlopen.

This would be a native code module? 

> 
> > GNU Mud anyone?
> 
> Naming it GNU Mud is at least misleading if it's not GPL'd, and as much
> as I like the Gnu Public License, it doesn't fit this project.

No GNU please.  Something else...  

Beerware!?   ;)
 
 
--
--/*\ 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   /*\--