>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:17 AM 8/6/2001 -0400, Uri Guttman wrote:
>> a few pseudo-random thoughts, take them as pure musings.
>>
>> 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.
DS> The dispatch is simple. We vector off a dispatch table, and we
DS> make it easy to vector to a different table whenever we need to.
but a pure 32 bit table can be very large (and sparse) if we have those
gaps you seem to propose below.
>> 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.
DS> This is a clever idea, and a good one except... there's no way to
DS> guarantee that two modules don't use the same value in the module
DS> table index. That means the only way we can make sure that there's
DS> no overlap is to process the module code as it's loaded, and that
DS> makes a hash of read-onlyness. It also means doing bitfield
DS> manipulation on each opcode as it's processed.
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> Don't forget (or BTW, if this hasn't come up before) that we'll
DS> likely have a fairly large number of new opcodes generated--if a
DS> sub is qualified to be treated as an opcode function, we probably
DS> will.
all the more reason to have a split op code and module index. it makes
it very easy to add new stuff at run time.
to simplify the mask/shift stuff, we could make it a 16 bit module and a
16 bit op code. a max of 64k loaded modules seems to be more that anyone
could want. depending on the architecture, those values could be fetched
with mask and shift (alpha) or direct 16 bit accesses.
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?
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
