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

Jon A. Lambert jlsysinc at ix.netcom.com
Wed Oct 21 20:29:26 CEST 1998


On 20 Oct 98, Marc Hernandez wrote:
> On Tue, 20 Oct 1998, Jon A. Lambert wrote:
> 
> }Stack-based or psuedo-register based?
> 
> 	Does a psuedo register system create any real benefit?  They are
> still implemented as memory locations AND have the additional benefit of
> having to be saved and loaded (unless there is some nice benefit I didnt
> think of (which is very possible (like reading lisp?))).
>

IIRC, Java makes use of 4 psuedo-registers in addition to a stack.  
It's a mechanism to save instructions executing some arithmetic 
operations and some loop constructs.  It also makes native code 
generation more straight forward.  It's really an optimization issue. 
Reading and writing to a pseudo-register will always be cheaper
than pushing and popping a stack.  There's no stack pointer to
increment or decrement.  :)

> }Details:
> 
> }Primitive data types to be represented.
> }Complex data types (object).
> 
> 	Why?

Will the language be oject-oriented?.  
 
> }Label generation.
> 
> 	hmmm.  Isnt this only for the assemblers benefit?  Why not skip to
> memory locations?

Well there may be some benefits to decompilation and/or pretty 
printing, if that's a desired feature.  Yes, you can easily forego 
label generation and use offsets.

> }Symbolic storage.
> }Variable storage.
> }Type conversions/promotions.
> 
> 	Isnt this basically a compile time issue? 
> 

It depends.  If a compiler supports very weak typing, type 
conversions must be done at run time. 

A sample, (see Coolmud)

var A;
A = "string";
A = 1.57

And there are type promotions to consider:

float A;
int B;

A = B * 1.4;

Is B temporarily promoted to a float at runtime?

> }Booleans/conditionals.
> 
> 	necessary for looping/control.  Doesnt have to be true booleans.

Right.  I actually meant boolean operations like (x AND NOT y).

> }Operator precedence.
> 
> 	operator precedence is taken care of by the compiler (else
> expression evaluators would be very easy to right :-) ).
>

Nod.  

> }Unique ID's are crucial to object manipulation.  For instance the 
> }interface to a ROM drop in might be object/room vnums.  Those objects 
> }would have no methods of course.  I would think the specifications 
> }for "object" would be a custom interface.  A generic way to descibe 
> }an object to the VM would be needed.  
> 
> 	Such as leave it as 'memory' and let the language impose its own
> structure to it.  (like the fact that there are no 'signed' integers to
> the processor.  Just sets of bits with operations on them.  We impose the
> fact that _these_ four bytes are a signed integer and thus we use
> SignedAdd etc).

I'm not sure.   How does the language address the object Player or 
the attributes of object Player?

--
--/*\ 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-archive mailing list