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

Re: Opcode Dispatch

Thread Previous | Thread Next
Uri Guttman
August 6, 2001 09:51
Re: Opcode Dispatch
Message ID:
>>>>> "DS" == Dan Sugalski <> writes:

  >> but a pure 32 bit table can be very large (and sparse) if we have those
  >> gaps you seem to propose below.

  DS> True, but only if we actually use the whole set. We're 32 bit for a few 
  DS> reasons, none of which are to provide a billion opcodes:

i never assumed a billion op codes, just a sparse table which could fill
it up a great deal.

  DS>    * So all the pieces of the op stream are the same size
  DS>    * It avoids alignment problems we'll see on many processors
  DS>    * It means the endian preprocessor we'll need on some platforms can be 
  DS> very fast, as it can just byteswap everything rather than actually need to 
  DS> know which pieces are which size.

i agree with those reasons.

  DS> Basically everything gets compacted down at one end, and we'll
  DS> probably (dynamically) limit the table size to 1K custom opcodes
  DS> in force at once or something.

i think i see your plan. i will try to write up my view of it below.

  >> well, i did say this would require some load time link stuff. i don't
  >> see why this mungs read-onlyness. the module index struct would have a
  >> readonly flag or something. if you modify the byte stream, you get a new
  >> op code block which can replace the current one for this module

  DS> Urk. Too much potential processing. Plus that still means we need
  DS> to divide up the opcode number, and that means a mask & check for
  DS> each opcode. Too much work.

  >> i just don't see how you can use a single integer op code without
  >> splitting it. what ideas do you have to handle loading modules with
  >> their byte stream and private op codes?

  DS> Simple. As I said, the opcode function table is lexically
  DS> scoped. Jump into code from another scope and the 'correct'
  DS> function table is automagically (well, OK, there's an opcode for
  DS> this, but...) installed for you. So while opcode 774 used to be
  DS> "socketpair", in the new lexical scope it might be
  DS> "LWP::Simple::get", but that's OK because since we swapped in a
  DS> new table everything's just fine.

so my take on that is that each module would compile to a byte stream
which has its own private op code table to dispatch ALL op code
functions called by this module. so the same op code index in two
different modules can (and probably will) map to different functions.

that works for me. it does eliminate the shift/mask stuff and link stuff
i had envisioned. it does require the compiler to generate a custom op
code table for each module (including main::). that will be a minor and
fixed overhead for compile and run operations.

how will it affect debugging or disassembly? you will have to be able to
convert a local op code to a symbolic name by some sort of reverse
lookup in the local op code table. since the op code table is currently
just a function dispatch table, this would need another table which maps
the op codes to sym names and such.

but i see the op code design solidifying which is my main goal. we have
been running around too much and i like seeing bryan's tests and your op
code engine notes. when you finish your draft PDD on this, bryan can
rewrite his tests to map your design which will be useful for both
benchmarking and prototyping.


Uri Guttman  ---------  ----------
SYStems ARCHitecture and Stem Development ------
Search or Offer Perl Jobs  --------------------------

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About