[MUD-Dev] Re: PDMud thread summary

[Jon A. Lambert]

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   /*\--