On Fri, 10 Oct 2003, Leopold Toetsch wrote:
> - the opcode numbers are assigned dynamically:
> When you load an oplib containing 100 ops, they get op numbers
> e.g. 1206 ... 1305. Next oplib starts at 1306 ...
> - on load all runcores are notified to use the new oplib function
> or address table
I've been thinking about this, and I've decided that loading oplibs and
installing those oplib functions in the current table should be separate
things. The load can do whatever it wants to initialize, but when the
functions are installed in the opcode dispatch table that's when the
interpreter says where the functions should go.
> There are for sure issues e.g. when you run the CGP core and the loaded
> lib has functions only, but a default handler in the jump table can
> call these functions then. The switched core also need this default
> handling.
>
> > ... Parrot_lib_load_%s ...
> > ... returns a PMC representing the library
>
> Any hints, what kind of PMC that shall be?
> An new Parrot_Lib PMC with the dll handle attached + some flags about
> the library and its contents?
At the moment, no. I knew we'd want a thing to hang stuff off of, hence
the PMC mandate. I'm not sure what that stuff should be yet, nor what we
might want to make it do. We can throw it into a ParrotLibrary PMC and
think about it as we go.
Dan
