On Fri, Oct 10, 2003 at 05:44:05PM +0200, Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > 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
What happens if the opcode library is rebuilt with more ops after the bytecode using it is compiled and frozen to disk? Even if the new ops are numbered (correctly) after the existing ops, if the loader just allocates op numbers on loading continuing after the last op number of the previously loaded library, than as soon as any op library gains an extra op, anything loading after it goes horribly wrong. (Likewise if an op library keeps the same number of ops, but itself gains a new dependency on an external op library) > How or from where is the second stage then done? > > Currently it would look like this: > > loadlb P1, "myops_ops" > fortytwo I0 > > C<loadlib> calls F<Parrot_load_lib> which calls F<Parrot_lib_<%s>_load>. > This would call back and run C<oplib_register>. That installs the opcode > dispatch tables. > > The assembler must do the same thing (as it does with dynamic PMCs) to > get the same opcode numbers (or class enums respectively). > We could actually defer installing the opcode dispatch table at runtime, > but we must reserve the opcode number range, and the assembler must > at least be able to query the dynamic lib for valid opcode names. When > the first unknown opcode is to be run, then the real functions could be > put in place. Or am I getting confused and all this lookup is done by name? Nicholas Clark
