Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2003 at 05:44:05PM +0200, Leopold Toetsch wrote: >> >> - the opcode numbers are assigned dynamically:
> What happens if the opcode library is rebuilt with more ops after the > bytecode using it is compiled and frozen to disk? Its as invalid as currently bytecode is, when the fingerprint doesn't match. We must at least assure, that the opcount didn't change. This whole can of worms is related to version checking. We probably need a Version PMC that is used for all items loaded at runtime. Its a generalization of the current PBC fingerprint. >> 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? No. Its the same scheme I proposed for the event checker code. When an event gets scheduled the opfunc dispatch tables get entries that actually handle the event. When new opcode numbers are reserved, their function or address tables get entries that install the lib in the tables. The C<loadlib "oplib"> actually would schedule an event which is handled when the first loaded opcode is to be run. > Nicholas Clark leo
