[MUD-Dev] Re: PDMud thread summary

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Fri Oct 23 18:55:03 New Zealand Daylight Time 1998


[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.

 >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.

 >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.

 >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.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA




More information about the MUD-Dev mailing list