[MUD-Dev] Re: PDMud thread summary

Jon A. Lambert jlsysinc at ix.netcom.com
Thu Oct 22 15:12:48 New Zealand Daylight Time 1998

Niklas Elmqvist wrote:
> The inter-module communication and standard calling conventions must be
> resolved before anyone can start building modules, for example.

A proposal...

Why not generate an import definition for each byte-compiled function.  The definition
would be written as a header of the module and saved with it.

Registering and unregistering the module is done by loading the header information
or deleting it from a table known to the driver or VM.

An example header entry protocol using name-mangling:

#module at function!offset$arg1$arg1...$argn
Where #module is the module or class name
Where @function is the function name, method name, or dataname
Where !offset is the relative offset to executable bytecode or symbol table
Where $arg entry would be of the following format

$ style type 

Where style would be:
             a argument 
             r  return
             d data member

Where type would be:
             v    void
             c   char
             i    int
             s   string
             f    float
             e     complex - followed by typename
             p     pointer  - prefix

Some examples using C/C++ style as Mud language:

In module "magic" we have the following functions:

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

For a typical C++ class: 

class foo {
int x;
string name;

foo() { /* intitializer */ }
int operation(float v) { /* blah blah */}

would generate the following headers:

---->  #foo at x!0x08000000$di
        #foo at name!08000004$ds
        #foo at foo!00000000$av
        #foo at operation!00000010$ri$af

Note this could be expanded on with other features(public,private), datatypes, etc.

When registering a module by reading the headers in one would be creating symbol
tables.   Relative offsets can be resolved to virtual memory locations.  Perhaps modules
could be temporarily swapped out due to lack of use and have their offsets nulled out,
or set to high values to indicate they are invalid or locked.

Any thoughts...  Does this look familiar to anyone.  :)

More information about the MUD-Dev mailing list