Hi, I'm trying to resolve the issues we have with loading dynoplibs in different PBCs in differening orders (TT #1633). Briefly, the problem is: dynops get mapped to numbers by the compiling interpreter, but the running interpreter might not be able to support the same mapping due to having other extensions loaded simultaneoulsy.
I came up with 2 solutions to the problem: 1) Specify the dynop library dependancies of the bytecode in PBC. Put entries in the fixup table for all instances of dynop seen. At loadtime, rewrite the bytecode with the approriate numbers using the fixup table. Pro: rewriting bytecode is easy, just use the offsets in the fixups. Con: a fixup entry for every dynop use point could get expensive (in PBC size), discouraging the use of dynops and defeating the whole point. 2) Specify the dynop library dependancies and the number mapping of the bytecode in PBC. At loadtime, scan the bytecode for any dynops and rewrite them for the current mapping using the mapping specified in PBC for decoding. Pro: very similar to current PBC format. Con: scanning bytecode can be expensive as ops must be introspected to determine their opcode length. In a discussion with jnthn and sorear about the above 2 options, it was suggested that dynops be associated with bytecode segments. This way, the dynop mapping could be the same for the bytecode segment at both compile time and load time and we wouldn't have to modify bytecode at all. This permits or moves us closer to some desirable features: mmappable bytecode, loading dynops or libraries that use dynops with multiple active interpreters, control of ops availability for security contexts, etc... I see 3 solutions using this approach: 3) Have a separate ops table for every bytecode segment, switch tables on Parrot_switch_to_cs. Pro: very similar to how parrot works now. Con: requires a large table for every bytecode segment (all core ops + active dynops). 4) Have a global core ops table and a separate dynops table for every bytecode segment, switch dynops tables on Parrot_switch_to_cs. Pro: table for each bytecode segment is only as large as it needs to be. Con: requires op dispatch to choose between core and dynops tables. 5) Have an interpreter-wide core ops table and a separate dynops table for every bytecode segment. Copy dynops table to the top of core ops table on Parrot_switch_to_cs. Pro: one ops table, small per-segment cost. Con: much copying. All of these options have good and bad attributes, none of them jump out at me as the superior solution. Ideas? Peter Lobsinger _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
