On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote: > 3) Have a separate ops table for every bytecode segment, switch tables
3a) The core ops become merely a preloaded dynop table. Since you only pay for the ops you use (and a dispatch pointer is the same size as a single opcode_t), the huge table problem goes away. > 4) Have a global core ops table and a separate dynops table for every 4a) Keep op dispatch as now, but add a special _dynop op which redispatches through the dynop table. Con: slows down use of dynops slightly. If you want to be really fancy, add _dynop_0 .. _15 slots which are copied, in a hybrid of 5). 4b) All ops after the last core op become stubs that indirect-jump to the correct dynop. This could be very fast with a tiny bit of arch- dependant code to generate trampolines. -sorear
signature.asc
Description: Digital signature
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
