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)
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)?
Or just function 1?
(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{} ?)
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)
I also think I've not thought about it enough, and I've not played with the
current bytecode enough to work out what it's really up to. (currently,
wondering what an undef gv->NAME means, and why use constant; makes one)
I think my heads in a mess because in C there's a clear distinction between
what goes in header files (declarations, no definitions) and source files
(definitions, which are things that become object code) whereas in perl
a perl module in 1 file provides both directions to the perl compiler, and
definitions that become ops in the tree.
Maybe it will all work if the op tree generator makes bytecode as it goes
along, rather than bytecode being a reverse engineering of package symbol
tables.
Nicholas Clark
