At 02:17 AM 8/6/2001 -0400, Uri Guttman wrote:
>a few pseudo-random thoughts, take them as pure musings.
>
>dan has ordered^Wsuggested that the op code be a 32 bit value.
Got it right the first time. "Ordered" is as good a word as any. ("Mandated
in the fundamental design documents" is a good way too... :)
>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 dispatch is simple. We vector off a dispatch table, and we make it easy
to vector to a different table whenever we need to.
>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.
This is a clever idea, and a good one except... there's no way to guarantee
that two modules don't use the same value in the module table index. That
means the only way we can make sure that there's no overlap is to process
the module code as it's loaded, and that makes a hash of read-onlyness. It
also means doing bitfield manipulation on each opcode as it's processed.
Don't forget (or BTW, if this hasn't come up before) that we'll likely have
a fairly large number of new opcodes generated--if a sub is qualified to be
treated as an opcode function, we probably will.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
