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). > 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. Sub/Classes i.e. parrot code is a little different. It has a different opcode (load_bytecode). This can be PASM, PIR, or PBC. The former two are compiled immediately, because the PMC Sub symbols must be installed for global lookup. Predereferencing and or JITing happens on demand, this is, when the first subroutine is invoked in that loaded bytecode. > Before I go any further, I want to make sure this makes sense to everyone. Yep. > Dan leo
