Re: Opcode Dispatch

Front page | perl.perl6.internals | Postings from August 2001

Thread Previous | Thread Next

From:

Uri Guttman

Date:

August 5, 2001 23:17

Subject:

Re: Opcode Dispatch

Message ID:

200108060617.CAA17742@home.sysarch.com.

>>>>> "BCW" == Bryan C Warnock <bwarnock@capita.com> writes:

  BCW> What may also need to be considered is what the expected growth
  BCW> of opcodes may actually be in future versions of Perl.  In order
  BCW> to maintain upwards compatability, future opcodes will need to be
  BCW> added around the current set.  If the initial set fills the
  BCW> entire primary table, for instance, then any future opcodes will
  BCW> need to buried behind an escape code.  It may be better to
  BCW> reserve space in the primary block for future use.  In addition,
  BCW> if the number of opcodes grows beyond 511, you'll need to extend
  BCW> three levels deep for dispatch, unless you allocate a small block
  BCW> on the primary table for multiple escape characters.

  BCW> Anything else to consider? Anything faulty in my approach or
  BCW> conclusions?

a few pseudo-random thoughts, take them as pure musings.

dan has ordered^Wsuggested that the op code be a 32 bit value. he didn't
like the escape code and 16 bits was too small a space. but i haven't
heard him spell out the op code dispatch design for that. so, here is a
way to use a 32 bit op code and support dynamic loading of byte code and
their private op code space.

the main idea is to break up the 32 bits into 2 integers which are the
module's op code table and the op code within a table. a reasonable
split of 20 bits for the module table index and 12 (4096) bits for the
op code table would be easy to work with and have no serious limitations
on expansion. this is just like the splitting an IP address into network
and host numbers.

so each module could load its own op code byte stream as well as an
optioanl private table of its own op codes (created by the new op and
syntax override whatever). when loaded it gets a unique module index and
that references its byte code and op code dispatch table.

so ::main would have module index 0 and its op code table would have all
the 'core' op codes in vanilla perl. the top level compiled byte code is
attached to this index as well.

if you load a module, it gets index 1 and has its byte code attached to
this index. if it defines any new op codes, that table is also attached
to the module index.

most generated code will use the core op code set in index 0
(main). only custom op code modules will be allowed to generate 

executing op codes is simple. you get the aligned 32 bit op code, do a
mask to get the module index, and a shift mask to get the op code. then
do the 2 levels of indexing to get to the op code function.

when modules are loaded they will need to do some linking so they can
refer to each other. this can be done on the fly and only when needed by
using a cache/lookup.

i think it is a very simple and flexible way to manage creating and
loading multiple modules which may create custom op codes. there are
plenty of gaps so attack away.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs  --------------------------  http://jobs.perl.org

Thread Previous | Thread Next