>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> 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
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
