[MUD-Dev] Re: PDMud thread summary
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
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