[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