Re: Opcode Dispatch

Front page | perl.perl6.internals | Postings from August 2001

Thread Previous | Thread Next

From:

Dan Sugalski

Date:

August 10, 2001 10:09

Subject:

Re: Opcode Dispatch

Message ID:

5.1.0.14.0.20010810130207.0216b460@tuatha.sidhe.org

At 12:32 AM 8/10/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <dan@sidhe.org> writes:
>
>   >> 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.
>
>   DS> Yup, though strictly speaking it's not on a per-module basis. If
>   DS> you compiled an entire program, from source, with all its modules,
>   DS> in one go and froze the whole mass to disk, you'd only have one
>   DS> opcode table. Of course, having said that, we're probably going to
>   DS> encourage folks to use the shared versions of modules, so we
>   DS> probably will ultimately end up with one table per module, more or
>   DS> less.
>
>hmmm. that implies some way of forcing all the modules to load and no
>main code to be executed before you dump the byte code.

Presumably they'll do something like:

   perlcc foo.pm foo.pc

to compile a module to bytecode.

>in compiling
>each module you have to be aware that they will be using the main
>dispatch table and not to create a private one perl module. this is sort
>of a compile/link phase in one operation.

Sure, but that's easy. The compiler phase only creates a single table. When 
you freeze to disk you freeze that table, and when you load a precompiled 
chunk of code you load its table with it.

>we need a document soon describing the creation and use of the dispatch
>tables. we have a fairly clear group vision but not enough on paper.

Working on it. We should have enough to start in on the back-end 
interpreter RSN.

>dan, do you have this in mind as a pdd?

Yup. It needs to be spec'd out as part of the disk-image of a 
program/module. I figure it's going to go into the architecture PDD. 
(Potentially after the fact, but that's OK)


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

Thread Previous | Thread Next