At 12:51 PM 8/6/2001 -0400, Uri Guttman wrote:
> >>>>> "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.
Can't happen. Since each compilation unit can assume a private opcode
table, they can all start filling from the beginning of the user-code
section and go contiguously.
> >> 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.
Yup, though strictly speaking it's not on a per-module basis. If you
compiled an entire program, from source, with all its modules, in one go
and froze the whole mass to disk, you'd only have one opcode table. Of
course, having said that, we're probably going to encourage folks to use
the shared versions of modules, so we probably will ultimately end up with
one table per module, more or less.
>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.
Given the other things the compiler's got to deal with, this is a
reasonably trivial thing. The linking loader will have to deal with some
fixup bits at module load time, but that shouldn't be much of an issue either.
>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.
Yup. More stuff in the symbolic table section for a compilation unit. Whee!
Can never have too many sections... :)
>but i see the op code design solidifying which is my main goal.
The opcode design, oddly enough, has been solid for months--this stuff
hasn't changed much at all since I originally sat down to doodle it out.
(Though some of the details are firmer, and the underlying VM
architecture's rather different than what I'd thought) The bigger issue is
that the VM design's solid, which has been what's holding this up. With
that done, it's reasonable and prudent to get all this moving.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
