[RFC] Dynop Opnum Mapping
Stefan O'Rear
stefanor at cox.net
Sun May 30 07:01:44 UTC 2010
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100530/862fa908/attachment.pgp>
More information about the parrot-dev
mailing list