James Mastros:
# On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote:
# > Here's what I'm thinking: The high 16 bits (or so) of the
# opcode can identify
# > the oplib (as an index to the table of oplibs, see the next
# para), the rest
# > can identify the opcode. This shouldn't be too bad a
# limit: 64k opcodes
# > perl oplib, 64k oplibs per packfile.
# Unfornatly, this seems to be a bit on the slow side:
#
(horrendous benchmarks cut)
#
# Right now, this is my DO_OPS:
# pc = interpreter->opcode_funcs[*pc>>24][*pc&0xFFF](pc, interpreter);
# I tried a 16/16 split as well, but core.ops is too big (293
# ops vs. 255 max).
# I also tried a 17/15 split, which had about the same speed.
#
# Ideas?
#
# Right now, I'm thinking that the opcodes are going to be
# assigned to oplibs
# linearly (eg the last opcode in core.ops is 292, so the first
# opcode in the
# next oplib loaded will be 293). However, this means that oplibs can't
# expand portably. It also just plain feels ugly.
How about, instead of just saying 'oplib foo' in the bytecode header, we
say 'first N opcodes of oplib foo'? After all, you generally don't have
any use for opcodes added after you assembled. :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, I'm not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
