On Tue, 14 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > ... We'd also rather not have to have separate .so/.dll/.exe files
>
> A small utility, that combines dynamic resources and emits a common
> load routine, which calls the individual load routines could be enough
> for this to achieve (modulo the same for init).
Yep, that's definitely in order as part of the extension building kit we
need to put together for Parrot's final release.
> > And, to make it more interesting, we don't want these things all
> > instantiated when we load in a library -- they need to be instantiated on
> > demand. So....
>
> This seems easily to be doable only for Parrot Subs / Classes.
> - a dynamic PMC has its enum_class_<Foo>, which the assembler has
> to know
> - a dynamic oplib has its opnumber range. Again the assembler has to
> load the lib to be able to spit out correct opcode numbers.
> For both cases, when run from source files, the assembler does the
> loadlib and the PMCs or oplibs are already installed. When running from
> PBC, this happens on execution of the C<loadlib> opcode, which has to be
> in the same sequence as the assembler has seen these C<loadlib> ops.
For PBC code, this is where metadata comes in. (Which means we can
potentially use it for on-the-fly assembled code as well) If a segment of
code is known to need an opcode library, then the bytecode loader should
make sure that library is loaded, instantiated, and that the opcode table
for the code segment is properly filled in.
Dan
