[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