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

RE: Opcode Dispatch

Thread Next
Garrett Goebel
August 10, 2001 15:25
RE: Opcode Dispatch
Message ID:
From: Uri Guttman []
> >>>>> "GG" == Garrett Goebel <> writes:
>   GG> Are we going to compile to bytecode every time, or might:
>   GG> perl
>   GG> create foo.pmc
>   GG> So that the next time is called for the bytecode could be
>   GG> reused instead of recompiling Assuming a checksum in
>   GG> foo.pmc says hasn't changed.
> if a module changes, do you force a rebuild?


> is it rebuilt automatically?


> do you use timestamps and/or checksums to see if
> a module changes?


And we might want the local perl compiler to recognize/certify the bytecode
it produces. Someone could always copy foreign bytecode produced by a
different compiler which is incompatible, corrupt, or hacked. So we'd need a
means for performing some limited bytecode verification too. 

> what tracks the module dependencies for the 
> purposes of a rebuild?

I'd assume if someone does a "perl foo", we'd check header info to determine
if foo is an executable, bytecode, or plaintext.

I don't really want to think about executables too much. I don't see the
point in embedding a perl interpreter if you're going to have external
module dependencies. I'd assume executables would in most cases be used in
situations where Perl isn't installed. Though Activestate's PerlApp utility
does allow you to turn a script into an executable which depends on Perl's
being installed.

I'm not sure about the module dependencies. I don't understand bytecode as
well as you do. I was surprised to see that:

  perl -MO=Bytecode,-ohello.pc -e "print qq|hello world\n|"

Results in a 200K hello.pc file!

Does everything and the kitchen sink have to go in there? I'm assuming
that'll be smaller in Perl6... or we'll wind up wasting too much disk space.

> do users need a make utility to track that and to force
> rebuilds?

Maybe I'm missing something due to my limited knowledge, but I'm hoping that
if uses that there'd be a foo.pc and foo.pmc. And that after
changes are made to, executing it would overwriting foo.pc, but leave
foo.pmc alone.

If we do need a make could the Perl Power Tools make be made to work?

> are real end users going to build byte stream versions?

We're making the bytecode, why discard it?

As to whether or not the execution of a user's script might result in a core
or site library being recompiled to bytecode... I'd punt that to a site
policy decision. But otherwise definitely yes where they have filesystem

> how are other byte stream languages dealing with these
> issues? we should do a study before committing to our design.
> this is a good topic for simon's language dev list.

Hmm... Is this time to plug simon's language dev list again?

> emacs has a similar problem with elisp and compiled elisp. but it can
> load/run either format and doesn't need to make them into standalone
> executables.
> in general, i see many possible pitfalls here so we should be clear on
> our goals before we do any design.

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