[MUD-Dev] Re: PDMud thread summary
Jon A. Lambert
jlsysinc at ix.netcom.com
Mon Oct 26 00:18:19 New Zealand Daylight Time 1998
On 23 Oct 98, Chris Gray wrote:
> Date: Fri, 23 Oct 1998 18:55:03 -0600
> From: Chris Gray <cg at ami-cg.GraySage.Edmonton.AB.CA>
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] Re: PDMud thread summary
> Reply-to: mud-dev at kanga.nu
> [Jon A. Lambert:]
> >I think Chris Gray mentioned fixing bytecode memory addresses
> >at startup, allowing direct jumps into functions. While a performance
> >boost, it makes dynamic registration and unregistration of modules
> >more complex.
> Yep. More complex, but not impossible. I guess my feeling is that
> module-unload events are fairly rare (module loading is pretty expensive,
> so you want to minimize them), so having to do a bit of work at that
> time, in order to save work throughout, may be a good trade-off.
Rare, unless modules can be instanced or otherwise replicated. I
mentioned that in another post tonight... I think we can support
both procedural languages and object-oriented languages as mud
languages. I'd prefer to support an object-oriented mud language,
which might require support multiple instances of modules (at least
any state they contain, not necessarily code)
> >Are function calls resolved at compile-time, registration, or run-time?
> Depends on what you mean by 'resolved'! Calls to visible names within
> a module should be resolved at compile time. Calls from one module to
> another that are fixed calls (not dependent on run-time data) can be
> resolved at registration (module load) time. Calls via pointers that
> MUD-code or module code can modify need to be at run-time. The comparative
> cost increases in that same sequence.
Would a successful compile automatically go ahead and register the
module? Any concerns here. I've always thought an automated mud
language source versioning system would be nice.
I agree with the above, but do we really want pointer accessability
and modification in any mud language implementation. Wouldn't this
compromise a security system. Maybe I'm misunderstanding the above?
> >Having the return value, buys nothing either, since the caller may not use
> >it and wouldn't be able to build a proper mangled name.
> >> int cast(int time, string spell) ----> #magic at cast!0x00000000$ri$ai$as
> >> char foo(char * bptr, bar i) ----> #magic at foo!0x1FBA2000$rc$apc$aebar
> >int cast(int time, string spell) ----> #magic at cast$ai$as
> >char foo(char * bptr, bar i) ----> #magic at foo$apc$aebar
> ?? By dropping the result type you are forcing run-time type checking
> and a data representation that allows that. That sort of thing may be
> wanted for other reasons, but the module interface descriptions aren't
> a problem for it. I'm missing whatever you are getting at here.
Agreed. The return type should be put back in.
What I'm getting at here with the name-mangling is a cheap and
reliable way to support polymorphism and inheritence.
> >For a standard call format, why not just have the caller push() it's address and then all the
> >arguments from left-to-right onto the stack then jump to the callee. The callee pops() them
> >out and loads local variables right-to-left. Return would pop() the return address off the
> >stack and push() the result and jump to the address just popped.
> Sure, that's fairly standard. The other thing you often want is for the
> return instruction to pop/deallocate any local variables as well.
Aye. How about support for static variables and recursion. We
haven't discussed module level variables (outside of functions).
--/*\ 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