Robert Spier <[EMAIL PROTECTED]> writes: > > The goals are to assign permanent numbers to the opcodes. What the > > numbers are is generally irrelevant, but they must be constant across > > all systems for the lifetime of parrot. > > At first glance, gut reaction, that seems "really hard"(tm) and > "really limiting"(tm)... > > since there's going to be a combination of dynamic oplibs that are > going to have to be dynamically numbered anyway. (right?) > > So why not treat the core oplib as dynamic? (With the exception of > the handful that need to be fixed, like end.)
Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. This scheme is extendable: Oplibs can append new ops to the end. If a bytecode doesn't know anything about this new ops it will overwrite this ops with ops from another oplib. But thats not a problem because the bytecode does not need this new ops. Problems might be two independ bytecodes using different versions of the oplibs. Then you have either to renumber the bytecode or use two independent opcode-tables. We can for sure define a base-lib which has all whats now in core, which is loaded by default starting at 256. A typical bytecode which just uses the base-lib has no extra load cost, because the lib is already there. Comments boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
