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

Re: Opcode Dispatch

Thread Previous | Thread Next
Stephane Payrard
August 10, 2001 11:00
Re: Opcode Dispatch
Message ID:
Hi Dan!

On Fri, 10 Aug 2001, Dan Sugalski wrote:

> At 12:32 AM 8/10/2001 -0400, Uri Guttman wrote:
> >>>>>> "DS" == Dan Sugalski <> 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.pc
> to compile a module to bytecode.

I hope have we will have something like arcc to combine many Perl
bytecoses librairies into one to avoid the cost of thousands of
mmaps. I read in linux-mm (?) that Mozilla is so slow on linux partly
because the peculiarities of glibc memory allocation schemes makes
Mozilla mmaping thousand of mmaps.

> >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
>                         have teddy bears and even
>                                      teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About