[MUD-Dev] Re: Bruce Sterling on Virtual Community goals
Jon A. Lambert
jlsysinc at ix.netcom.com
Wed Oct 21 20:29:26 New Zealand Daylight Time 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. :)
> }Primitive data types to be represented.
> }Complex data types (object).
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)
A = "string";
A = 1.57
And there are type promotions to consider:
A = B * 1.4;
Is B temporarily promoted to a float at runtime?
> 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 :-) ).
> }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