On Tue, Oct 03, 2000 at 12:27:03PM -0500, Jarkko Hietaniemi wrote:
> On Tue, Oct 03, 2000 at 05:32:48PM +0100, Nicholas Clark wrote:
> > 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?
>
> Mainly just 1.
> > 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)
>
> Serializing an optree is rather tricky especially if one wants to
> deserialize it on a different platform. Because of icky things like
> structure padding one effectively really needs to go the way of
> *byte*codes which makes for one ssslllooowww VM.
Ah. you were thinking that the bytecode dumped out by perl6 could well be
C structs analogous to the current OP and SV structs, rather than the
variable length byte instructions to rebuild the OP tree that that
B::Bytecode produces?
No. hangon. that's exactly what you were saying it should not be.
I was more thinking about the current "hack" in require that has a look for
a .pmc more recent than the .pm in @INC and if so uses that rather than the
.pm. However, current bytecode isn't as fast as the parser, neither is it
smaller, so currently there's no gain from doing this.
But if a non-portable per-file bytecode sat in @INC that was faster than
the parser would be worthwhile, surely?
[Particularly if the parser's optimiser could be told "you're parsing for
bytecode, so expensive optimisations that save little time are now a viable
plan" rather than the current compile once, run once optimisation]
But I seem to remember someone who should know (Tom Christiansen?) at
YAPC::Europe being confident that bytecode would never be faster.
Is emacs lisp bytecode portable?
Nicholas Clark
