[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

8510: [MUD-Dev] Re: PDMud thread summary

[Full Header] [Plain Text]
From: "Jon A. Lambert" <jlsysinc@ix.netcom.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 22 Oct 1998 15:12:48 -0400
Organization: Kanga.Nu
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@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@cast!0x00000000$ri$ai$as
char foo(char * bptr, bar i)    ---->  #magic@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@x!0x08000000$di
        #foo@name!08000004$ds
        #foo@foo!00000000$av
        #foo@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.  :)