Front page | perl.perl6.internals |
Postings from August 2001
Re: Opcode Dispatch
From: Stephane Payrard
August 10, 2001 11:00
Re: Opcode Dispatch
Message ID: 20010810200251.H2103@stef
On Fri, 10 Aug 2001, Dan Sugalski wrote:
> At 12:32 AM 8/10/2001 -0400, Uri Guttman wrote:
> >>>>>> "DS" == Dan Sugalski <firstname.lastname@example.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.
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)
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> email@example.com have teddy bears and even
> teddy bears get drunk