At 12:23 PM 8/6/2001 -0400, Uri Guttman wrote:
> >>>>> "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.
True, but only if we actually use the whole set. We're 32 bit for a few
reasons, none of which are to provide a billion opcodes:
* So all the pieces of the op stream are the same size
* It avoids alignment problems we'll see on many processors
* It means the endian preprocessor we'll need on some platforms can be
very fast, as it can just byteswap everything rather than actually need to
know which pieces are which size.
Basically everything gets compacted down at one end, and we'll probably
(dynamically) limit the table size to 1K custom opcodes in force at once or
something.
> >> 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
Urk. Too much potential processing. Plus that still means we need to divide
up the opcode number, and that means a mask & check for 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?
Simple. As I said, the opcode function table is lexically scoped. Jump into
code from another scope and the 'correct' function table is automagically
(well, OK, there's an opcode for this, but...) installed for you. So while
opcode 774 used to be "socketpair", in the new lexical scope it might be
"LWP::Simple::get", but that's OK because since we swapped in a new table
everything's just fine.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
