Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:10 +0200 7/31/03, Leopold Toetsch wrote:
>> > *) Determine the init and setup routine names
>>
>>- Parrot_<classname>_class_setup
>>- Parrot_<classname>_class_init
>>
>>The class_setup also sets the class_enum i.e vtable->base_type.
> Well... there are versioning issues there. We ought to be able to
> have multiple versions of a class loaded, in which case this may not
> work. I'm pretty sure that there are some platforms that require
> unique names in libraries across the entire process.
What about the following (also considering, that we might not like one
handle/mmap... per PMC, as stated in one f'up):
A dynamic PMC library has one init function returning a dyn_pmc_info
structure:
struct { /* pseudo code */
int n_pmcs; /* count of pmcs in this extension file */
struct {
char *class;
version_t version;
(*pmc_setup_func)();
(*pmc_init_func)();
} pmc_info[n_pmcs];
} dyn_pmc_info;
And e.g. these opcodes:
load_pmc "foo" # load $(RUNTIME_LIB)foo$(SO), class Foo
load_pmc sx, sy # load lib sx, class sy
load_pmc sx, sy, sz # load lib sx, class sy, version sz
So a PMC extension could contain e.g. all PMCs needed for one specifc
language including PMCs of same functionality but different versions.
We only need the name of the init func.
More things to consider:
- the assembler has to see the same sequence of B<load_pmc> opcodes as
runtime (the loaded class gets the next available class enum, which
must match the B<new_p_ic> class_enum)
- or we have to put this info into some metadata, so that classes are
loaded in correct order at runtime
- we need global and per interpreter structures to keep track of
loaded extension libs.
Comments welcome,
leo
