At 05:32 PM 10/3/00 +0100, Nicholas Clark wrote:
>On Mon, Oct 02, 2000 at 07:21:46AM -0500, Jarkko Hietaniemi wrote:
> > Having such bytecodes available is essential for the proposed
> > functionality of dumping the state of a live and running Perl virtual
> > machine and breathing life into that later.
>
>Were you thinking that p6 bytecode has 2 functions
>
>1: putting a perl virtual machine into suspended animation (or cloning it)
Yep.
>2: producing a "precompiled" version of a single file of perl
> (ie .pmc is a drop in replacement for .pm, any use or require in the .pm
> still causes the .pmc to issue a use or require at run time)?
Yup here, too.
>(and bytecompiling a script gives you a single bytecode file which contains
>the exact versions of all libraries you used for it, freezing the virtual
>machine between the last CHECK{} and the first INIT{} ?)
Maybe. I'd like to make this a compile-time option--dump the whole thing or
just the stuff in the main file. If you choose just the stuff in the
current file then a set of "include XXX" bytecodes would get emitted.
>I think function 2 is somewhat tricky to implement, as one would be aiming
>to capture bytecode that represents the changes to the op tree that the file
>made. Without ensnaring changes to the op tree caused by modules it used.
>(problem being that there's not a 1 to 1 correspondence between files and
>packages)
We'd be doing it before the optree stage most likely. Yeah, it'll be a pain
but I think it's doable. (Possibly with some restrictions, but that's OK)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
